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Abstract 

Intrusion  detection  consists  of  determining  patterns  of  behavior  that  could  compromise 
the  integrity  of  a  computer  system  by  allowing  an  undesirable  intrusion.  This  work 
explores  the  use  of  Distributed  Computing  Environment  facilities  to  aid  in  developing  a 
commercial  grade  distributed  intrusion  detection  system.  After  studying  previous  work 
already  done  in  this  field,  prototype  development  was  conducted  to  detemnine  how  best 
to  use  the  DCE  Audit  and  Security  Services  to  perform  intrusion  detection  functions. 
Methods  were  developed  to  ensure  secure,  efficient,  scalable,  and  fault  tolerant 
communications  would  be  made  manifest  in  the  overall  architecture  of  the  prototype. 
Tests  were  conducted  independent  of  and  in  conjunction  with  previously  developed 
intrusion  detection  systems  from  outside  sources.  These  tests  strongly  indicate  that  a 
DCE-based  intrusion  detection  system  is  not  only  possible,  but  would  be  welcomed,  filling 
a  void  in  a  market  place  hungry  for  security  solutions.  Independent  investors  have 
committed  their  financial  support  to  see  this  work  continues. 
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1  Summary 

Beginning  on  June  25,  1997  Curriculum  Corporation  embarked  upon  a  “proof  of  Concept” 
exercise  in  support  of  the  project  DARPA  SB971-006  “System  and  Security  Management  Tools". 
Work  has  progressed  even  better  than  expected,  and  continues  to  support  the  intent  of  the 
original  proposal.  Endorsed  by  outside  investors,  we  are  confident  we  can  produce  a  commercial 
grade  Intrusion  Detection  System  that  will  be  unique  in  its  marketplace. 

The  primary  objective  of  the  project  is  to  determine  if  it  is  technicaiiy  feasibie  and  commerciaily 
viable  to  design  an  Intrusion  Detection  System  (IDS)  that  uses  the  Open  Group's  Distributed 
Computing  Environment  (DCE)  in  two  main  ways: 

1)  As  a  source  of  information  that  might  iead  the  IDS  to  detect  an  intrusion. 

2)  As  a  security  infrastructure  that  can  be  utilized  to  respond  to  an  intrusion. 

The  DCE  Audit  Service  was  found  to  be  a  valuable  source  of  clues  to  possible  intrusions.  In 
much  the  same  way  that  traditional  Intrusion  Detection  Systems  obtain  clues  from  an  operating 
system’s  audit  trail,  the  proposed  DCE-based  solution  was  able  to  “observe”  anomalies  through 
the  DCE  Audit  Service.  Since  the  DCE  Audit  Service  audits  security-related  events  on  behalf  of 
each  system  in  its  cell,  it  was  discovered  that  it  is  possible  to  detect  “concerted  attacks”  across  a 
wide  range  of  systems  (within  a  DCE  cell). 

Prototype  code  produced  during  our  Phase  I  effort  shows  that  we  are  able  to,  on  the  fly,  deny  an 
intruder  access  to  resources  across  an  entire  DCE  cell  upon  detection  of  an  anomaly.  This  is 
accomplished  by  deleting  authentication  tickets  at  the  site  of  the  intrusion.  Further,  it  was  clear 
that  the  granularity  of  the  DCE  Access  Control  List  (ACL)  based  authorization  scheme  meant  that 
it  would  be  possible  to  provide  a  range  of  response  scenarios.  Our  approach  avoids  the  “denial 
of  service”  problems  associated  with  marking  a  login  account  as  invalid  by  ticket  deletion. 

Some  other  current  research  projects  in  Intrusion  Detection  focus  on  Intrusion  Detection  and 
Response  as  a  Distributed  Systems  problem,  i.e.  many  systems  must  “look  for”  possible 
intrusions  and  patterns  of  attack  across  many  systems.  Our  perception  of  one  of  the 
shortcomings  in  these  projects  is  that  they  build  their  own  (secure)  client-server  infrastructure 
within  vtdiich  distributed  components  can  communicate.  Our  belief  is  that  use  of  an  existing 
industry  standard  distributed  computing  infrastructure  (the  Distributed  Computing  Environment, 
DCE)  allows  us  to  focus  on  the  other  parts  of  the  Intrusion  Detection  problem  that  are  difficult  to 
solve. 

With  this  data  in  place.  Curriculum  Corporation  is  confident  that  K  will  be  able  to  develop  a 
commercially  successful  Intrusion  Detection  product  within  the  eighteen-month  window  provided 
by  SBIR  Phase  II. 
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2  Introduction 

Within  the  discipline  of  Computer  System  Security,  there  are  tools,  techniques,  and  tasks 
associated  with  preventing,  detecting,  and  responding  to  undesirable  events  within  a  computer 
system.  While  the  discipline  is  very  focused,  it  is  quite  diverse  in  the  range  of  topics  discussed. 
Some  topics  are  fairly  straight  forward  and  simple  to  use  such  as  Access  Control  Lists  (ACLs)  to 
grant  access  to  specific  resources  (e.g.  user  A  is  allowed  to  update  file  B).  Other  topics  are  more 
esoteric  requiring  sophisticated  algorithms  (e.g.  keystroke  signatures  to  detect  a  forged  identity). 

This  research  effort  focuses  on  the  non-trivial  task  of  detecting  and  responding  to  intrusive 
behaviors  in  a  dynamic  system.  While  this  is  not  a  new  area  of  study,  it  continues  to  be  of  great 
interest  since  it  has  serious  potential  in  effectively  supporting  complex  inter-connected  computer 
networks.  The  frequency  of  "attachments"  between  previously  isolated  networks  has  escalated 
with  the  advent  of  the  Internet.  Often  the  user's  demands  for  Internet  access  place  the  computer 
support  personnel  in  the  position  of  granting  the  access  through  the  private  network  to  achieve 
economy  of  scale.  Once  connected,  the  support  personnel  often  do  not  expend  the  effort  to  keep 
constant  vigil  on  potential  or  actual  attacks  upon  their  networks. 

What  is  needed  is  an  active  monitoring  system  that  can  detect  and  respond  to  attacks  as  they 
happen.  This  system  must  adapt  to  the  changing  nature  of  the  overall  system  without  being 
readily  "spoofed"  by  the  would-be  attacker.  Generically,  these  systems  are  referred  to  as 
Intrusion  Detection  Systems.  They  take  various  forms  of  implementation  based  on  the  premise  of 
their  design.  Early  efforts  focused  on  a  single  system  while  recent  efforts  focus  on  the  collection 
of  systems  connected  via  some  network  technology.  Generically,  this  latter  focus  is  referred  to  as 
"distributed  systems"  and  commonly  involves  many  systems  of  diverse  types  (e.g.  IBM  OS/390 
and  AIX,  DEC  VMS  and  OSF/1,  Microsoft  Window  95  and  Windows  NT,  Sun  Microsystems 
Solaris,  Hewlett-Packard  HP-UX). 

Perfonning  intrusion  detection  in  a  distributed  system  is  far  more  complex  since  vulnerabilities 
increase  with  the  number  of  and  differences  between  the  systems  involved.  Often  the  distributed 
intrusion  detection  systems  have  focused  on  one  class  of  platform  (e.g.  UNIX)  to  reduce  the 
complexity  of  the  task  involved.  The  objective  of  this  research  uses  a  multi-vendor  distributed 
infrastructure  technology  (Open  Software  Foundation  (OSF)  Distributed  Computing  Environment 
(DCE))  to  create  a  distributed  intrusion  detection  system.  OSF/DCE  is  widely  available  and 
provides  security  features  which  can  enable  and  support  intrusion  detection  efforts. 

2.1  Purpose  of  the  Research 

Curriculum  Corporation  proposed  to  research  and  develop  an  innovative  platfonm-independent 
intrusion  detection  and  response  tool.  The  tool  would  use  Open  Software  Foundation  (OSF) 
Distributed  Computing  Environment  (DCE)  technology  in  order  to  support  a  diverse  mixture  of 
mainstream  computer  platforms.  This  tool  would  use  the  features  inherent  in  the  DCE  Security 
Service  to  detect  and  respond  to  intrusions  on-the-fly. 

2.2  Scope  of  the  Research 

Intrusion  detection  has  been  an  area  of  study  since  the  early  1980's  and  yielded  products  which 
examine  various  aspects  of  a  system's  vulnerabilities.  Since  DCE  is  a  newer  standard  that 
provides  a  centralized  security  model,  work  needed  to  be  done  to  develop  and  integrate  DCE 
features  into  previous  intrusion  detection  efforts.  The  primary  focus  of  the  initial  research 
proposal  discussed  herein  related  to  the  use  of  DCE  features  toward  intrusion  detection. 
Microsoft  has  now  announced  that  the  centralized  security  service  in  NT5.0  Domains  will  be  an 
implementation  of  kerberos  V  Oust  as  DCE  is)  using  DCE  Remote  Procedure  Calls  (RPCs).  It  is 
now  clear,  therefore,  that  our  research  applies  equally  to  networks  of  systems  using  NT  Domain 
Controllers.  This  implies  a  wider  marketplace  than  initially  envisaged. 
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2.3  Report  Structure 

This  report  documents  the  research  efforts  as  they  unfolded,  highlighting  significant  DCE  "value 
added  functionality.  Ultimately  an  initial  architecture  and  elementary  prototype  from  which  a 
commercial  grade  product  could  be  built  is  the  end  result  of  this  research  effort. 
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3  Methods,  Assumptions,  and  Procedures 


3.1  Identification  of  the  Problem  Being  Addressed 

Traditionally,  much  Intrusion  Detection  work  has  focused  on  examination  of  an  audit  trail  from  a 
single  UNIX  system  and  making  predictions  about  a  possible  intrusion  based  on  this  local  data. 
Curriculum  Corporation's  research  focuses  on  developing  a  platform  independent,  heterogeneous 
intrusion  detection  and  response  tool  based  upon  OSF/DCE  technology.  The  technical  problems 
being  addressed  are: 

1)  Today's  Intrusion  Detection  Systems  (IDSs)  are  mainly  applicable  to  UNIX 
environments  (few  support  Windows/NT  or  IBM/MVS)  and  none  are  deployable 
across  all  operating  systems. 

2)  Automated  responses  to  intrusions  are  often  not  implemented.  Response  needs  to 
be  fast  and  thus  automation  is  a  vital  component. 

3)  Most  IDSs  have  high  "false  alarm"  rates.  This  has  inhibited  automation  efforts. 

4)  IDSs  are  being  developed  for  distributed  environments  but  usually  these  IDSs  are 
developed  using  proprietary  and  specially  developed  unique  communication 
infrastructures  for  them.  This  makes  "porting"  to  divergent  platform  expensive. 

5)  It  is  currently  a  non-trivial  task  to  interface  one  IDS  with  another  since,  until  recently, 
no  common  API  existed. 

6)  Intrusion  Detection  problems  also  exist  in  HUGE  computing  environments  (thousands 
of  systems  in  a  single  site).  Existing  IDSs  do  not  effectively  scale  to  support 
environments  this  size. 

Our  Phase  I  proof  of  concept  work  has  indicated  that  we  can  advance  the  state  of  the  art  in 
Intrusion  Detection  by: 

1)  Providing  an  enterprise-wide  solution  detecting  anomalies  on  at  least  the  following 
operating  systems:  Solaris,  HP-UX,  AIX,  NT,  MVS 

2)  Providing  an  immediate  response  facility  affecting  each  of  those  operating  systems 
listed  above.  The  response  shall  be  implemented  aaoss  one  thousand  systems 
within  one  second. 

3)  Focusing  much  effort  in  the  area  of  elimination  of  Talse  positive”  indications  of 
intrusion  (through  use  of  multiple  independently  developed  Intrusion  Detection 
engines  and  refinement  of  those  engines,  rather  than  invention  another  ID  engine). 

4)  Utilizing  a  secure  industry  standard  security  and  communications  infrastructure  (DCE 
RPC),  therefore  saving  time  that  otherwise  would  be  needed  for  creation  of  a  security 
and  communications  infrastructure. 

5)  Implementing  the  forthcoming  Common  Intrusion  Detection  Framework  (CIDF)  to 
facilitate  re-usability  of  components  and  interoperability  with  other  Intrusion  Detection 
products. 

6)  Leveraging  the  scalable  DCE  infrastructure  (which  supports  tens  of  thousands  of 
clients  in  a  single  cell)  by  interfacing  with  the  DCE  Security  and  Audit  Service.  The 
DCE  Security  Service  only  audits  security  related  events  and  can  therefore  support  a 
cell  encompassing  very  large  numbers  of  clients). 

The  tool  set  that  we  have  prototyped  makes  up  an  enterprise-wide  (scalable)  detection  and 
response  system  that  is  not  tied  to  a  specific  operating  system  type.  The  proposed  system  is 
able  to  identify  possible  security  anomalies  and,  in  real  time,  transform  the  way  that  every  system 
in  a  DCE  cell  behaves,  in  order  to  respond  to  the  anomaly.  A  design  goal  is  to  be  able  to  alert 
many  systems  in  a  very  short  interval.  The  proposed  tool  will  allow  very  large  numbers  of 
desktops,  midrange  systems,  and  mainframes  to  react  in  concert  to  a  possible  security  attack. 
The  distributed  nature  of  the  design  allows  for  a  very  agile  response  as  well  as  a  speedy  return  to 
normal  work  within  a  heterogeneous,  secure  environment  such  as  DCE  where  a  concerted 
response  to  an  attack  can  be  easily  implemented. 


Printed  01/19/98 


Page  5 


One  of  the  major  technical  challenges  with  any  Intrusion  Detection  System  (IDS)  is  to  eliminate 
virtually  all  false  alarms.  After  our  six  months  of  research,  Curriculum  Corporation  believes  that  it 
would  be  infeasible  to  build  an  entirely  “false-alarm-free"  system  from  the  ground  up.  Our 
research  indicates  that  much  other  work  has  been  done  in  building  good  detection  engines,  but 
that  not  as  much  has  been  done  on  tuning  these  engines  for  reliable  use  in  a  large  distributed 
environment.  We  intend  to  license  components  of  existing  IDSs  (including  independently 
developed  rules  etc)  and  compare  the  results  of  these  IDSs  with  those  of  our  detection 
component  (which  monitors  an  entire  network)  in  order  to  reach  consensus  on  likelihood  of 
attack.  By  licensing  previous  R&D  works,  we  believe  we  can  build  upon  a  huge  accumulated 
knowledge  base  and  apply  a  more  pragmatic  approach  to  reduction  of  false  positives.  Other 
research  in  Intmsion  Detection  also  validates  the  claim  that  the  Detection  Engine  itself  is  no 
longer  the  only  key  element  in  a  distributed  IDS,  but  just  one  part  of  a  larger  application  suite. 
Our  research  also  shows  that  our  centralized  approach  to  detection  facilitates  identification  of 
trends  across  an  enterprise. 

3.2  Phase  I  Objectives 

Our  Phase  I  technical  objectives  were: 

1)  Determination  of  a  wide  range  of  intrusion  scenarios  that  can  be  identified  by  the 
combination  of  DCE  Audit  and  our  proposed  IDS. 

2)  Determination  of  a  range  of  responses  to  the  intrusion  scenarios  identified  above. 

3)  Design  and  implementation  of  prototype  intrusion  detection  and  response  tool. 

All  of  these  three  objectives  were  addressed  and  we  are  confident  that  there  are  no  major 
obstacles  to  completion  of  a  pragmatic,  distributed  Intrusion  Detection  System.  This  system 
extends  the  state  of  the  art  in  a  number  of  ways.  With  this  in  mind.  Curriculum  has  sought  and 
obtained  enthusiastic  outside  reputable  investors  to  support  a  Phase  II  fast  track 
application.  This  application  reflects  the  company’s  strong  belief  that  an  excellent  state  of  the 
art  commercial  grade  IDS  can  be  created  in  Phase  II. 

We  believe  that  two  other  major  factors  make  our  goals  attainable  in  the  Phase  II  timeframe: 

1)  Unlike  other  distributed  IDS  development  projects,  we  shall  make  use  of  an  existing 
communications  and  security  infrastructure  i.e.  DCE  security  and  RPC.  This  should  save 
tremendous  amount  of  “development  the  infrastructure"  time.  DCE  already  has  a 
client/server  environment  that  scales  to  very  large  environments  and  has  many  years  of 
proven  experience  in  large  production  environments. 

2)  We  intend  to  license  (rather  than  re-invent)  some  subset  of  our  Intrusion  Detection 
engine  components.  This  will  allow  our  company  to  build  upon  work  already  done,  and 
focus  on  other  areas  of  technical  challenge  (such  as  high  false  alanm  rates). 

3.3  Phase  I  Tasks 

The  following  tasks  were  outlined  in  the  Phase  I  proposal: 

3.3. 1  Task  1.  Configure  a  Heterogeneous  Test  Environment 

A  test  environment  comprising  the  following  operating  systems  was  successfully  configured- 
SunSoft  Solaris,  Windows  NT,  IBM  AIX,  OS/2,  HP-UX 

The  IBM  AIX  system  and  the  HP-UX  system  were  configured  to  replace  the  underlying 
authenticatiori  scheme  of  the  native  operating  system  with  that  provided  by  a  centralized  DCE 
Security  Service.  This  forces  every  user  authentication  request  to  use  the  DCE  Security  Service 
(and  therefore  be  audited  in  a  central  location). 

The  Solaris  and  AIX  systems  were  configured  to  use  a  file  system  based  on  DCE  (the  DCE 
Distributed  File  Service  -  DFS).  This  has  the  effect  of  forcing  (new)  user  file  requests  (for  files 
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stored  in  DFS)  to  generate  a  DCE  ticket  request  to  the  DCE  Security  Server.  These  requests  can 
be  detected  through  the  DCE  Audit  Service  (and  therefore  our  IDS). 

3.3.2  Task  2.  Design  an  Interface  to  the  Audit  Service 

Both  the  AIX  and  Solaris  systems  in  our  test  environment  were  configured  to  run  the  DCE  Audit 
Service.  A  prototype  application  was  written  that  queried  the  Audit  Service  using  the  DCE  Audit 
API  to  look  for  possible  security  anomalies.  The  prototype  was  a  success.  This  code,  see 
Appendix  A,  may  be  used  as  the  basis  for  a  production  module  if  we  are  chosen  to  implement 
Phase  II.  The  prototype  interface  to  the  DCE  Audit  Service  was  abie  to  retrieve  fiitered  events 
that  were  considered  appropriate  for  intrusion  detection. 

3.3.3  Tasks.  Configure  the  DCE  Audit  Service 

The  DCE  Audit  Service  was  re-configured  so  that  aii  filtering  was  disabled.  This  allows  our  IDS  to 
perform  filtering  at  it’s  own  discretion  based  on  the  maximum  information  possible  from  the  DCE 
Audit  Service. 

3. 3. 4  Task  4.  Test  that  Intrusions  are  Detected 

A  number  of  intrusion  scenarios  have  been  obtained,  including:  1)  a  set  of  exploits  from 
personnel  at  Rome  Laboratories  and  2)  a  collection  of  exploits  obtained  from  numerous  “hacker” 
pages  on  the  internet.  [16,17,18,19,20,21,22,23.24] 

We  intend  to  obtain  many  more  scenarios  for  Phase  li  and  to  continue  to  test  that  these  potential 
intrusions  generate  events  in  the  DCE  Audit  Service  that  can  be  “seen”  by  an  Intrusion  Detection 
System.  It  is  clear  from  the  work  that  we  have  already  done  here  that  simple  intrusions  such  as 
password  guessing  attacks  can  be  detected  centrally  via  the  combination  of  our  prototype  tools 
and  the  DCE  Audit  Service. 

It  is  unlikely  that  centralized  audit  (such  as  the  DCE  Audit  Service  or  that  of  Kerberos  V  based  NT 
5.0  Domain  controller)  will  be  able  to  detect  every  intrusion  scenario.  For  example,  use  of  UNIX 
“setuid”  files  is  invisible  from  the  DCE  Audit  Service.  The  issue  of  setuid  file  accesses  is  primarily 
a  UNIX-only  issue  (and  DCE  Audit  is  more  heterogeneous),  but  there  were  other  exploits  that  did 
not  generate  auditable  events  through  our  audit  interface.  It  was  therefore  necessary  to  modify 
our  initial  architecture  (as  specified  in  the  Phase  I  application).  We  have  added  a  new  component 
in  our  architecture,  a  local  (lightweight)  monitor.  The  local  monitor  will  take  the  more  traditional 
approach  of  reading  local  UNIX  audit  trails  looking  only  for  only  a  limited  subset  of  patterns  that 
are  not  registered  in  our  centralized  audit  monitor  (e.g.  setuid/setgid  file  accesses  and  potentially 
other  operating  system  centric  areas  of  interest).  This  lightweight  monitor  is  much  simpier  than  a 
traditional  IDS  client  component  (to  help  in  portability  and  performance)  since  its  area  of  interest 
is  limited  only  to  events  not  detectable  centrally.  This  new  client  component  feeds  events  of 
interest  back  to  our  centralized  Audit  Monitors  via  secure  DCE  Remote  Procedure  Cails. 

3.3.5  Task  5.  Investigate  Appropriate  Response  Scenarios 

As  a  result  of  our  Phase  I  work,  the  following  response  scenarios  have  been  shown  to  be 
impiementable  in  phase  II: 

1)  Regeneration  of  a  machine  key 

2)  Account  disabling 

3)  Re-encryption  of  the  DCE  Security  Database 

4)  Regeneration  of  login  keys  used  by  authenticated  application  servers 

5)  Modification  of  the  behavior  of  the  DCE  Password  Strength  Subsystem 

6)  Imposition  of  stricter  auditing  requirements 

7)  Shortening  of  the  life  span  of  existing  and  future  tickets 

8)  Raise  an  appropriate  alarm  to  security  administration  staff 

9)  Temporarily  disable  each  DCE  administrator  account 

10)  Shut  down  applications 


Printed  01/19/98 


Page  7 


3.3.6  Tasks.  Prototype  Responses 

The  simplest  response  to  an  intrusion  is  to  temporarily  invalidate  the  login  account  being  used  by 
an  intruder  and  to  kill  the  processes  used  by  that  intruder.  In  the  context  of  a  DCE-based  security 
infrastmcture,  these  tasks  would  involve  marking  a  login  account  as  invalid  (in  the  centralized 
DCE  Security  Service),  and  setting  the  “good  since”  (date)  attribute  on  the  tickets  associated  with 
this  account  to  a  dateAime  in  the  future.  It  was  anticipated  that  these  two  operations  would 
immediately  revoke  authorization  for  all  tasks  that  require  authentication.  It  turns  out  from  our 
tests  that  there  is  currently  a  serious  bug  in  the  DCE  Security  Service  that  allows  an  identity  to 
continue  to  perform  privileged  tasks  despite  the  steps  previously  described.  These  steps  are  the 
appropriate  steps  as  documented  by  the  OSF.  The  problem  has  been  reported  to  responsible 
vendors  and  we  anticipate  a  fix  across  all  DCE  platforms.  As  a  fallback  position,  we  have  tested 
that  we  can  implement  a  local  ticket  revocation  that  would  render  an  intruder  harmless.  This 
solution  however  is  less  elegant  than  the  steps  described  previously  since  these  only  operate  on 
the  centralized  security  server  and  do  not  require  our  IDS  to  make  any  local  operations  on  client 
systems. 

We  learned  that  more  granular  modifications  to  the  DCE  infrastructure  can  form  a  response 
without  potentially  jeopardizing  day-to-day  operations.  For  example,  if  an  intruder  were  to  obtain 
the  login  identity  of  (say)  a  business-critical  DCE-based  database  server  (all  DCE  processes 
have  their  own  identities)  then  the  effect  of  invalidating  the  login  account  for  the  database  server 
would  be  to  create  a  denial  of  service  to  the  rest  of  the  company.  It  is  anticipated  that,  in  Phase 
II,  we  can  make  use  of  the  granular  Access  Control  List  mechanisms  protecting  the  DCE  security 
infrastructure  to  implement  a  range  of  responses  to  attacks  of  this  kind. 

3.3. 7  Task  7.  Performance  Tests  for  Secure  Broadcast  DCE  RPCs 

As  described  below,  the  original  "secure  broadcast”  approach  was  proven  infeasible.  An 
alternative  technology  was  developed  and  proven  to  be  viable  in  a  large  heterogeneous 
environment.  The  nature  of  the  alternative  proved  to  be  more  flexible  yet  providing  the  "quick 
response"  needed  for  the  rapid  transmission  of  the  alarm/response  notifications.  Using  low-end 
1990-vintage  workstation  hardware,  we  were  able  to  transmit  and  receive  (with  no  data  loss)  over 
1,000  typical  RPC  notifications  to  multiple  clients  in  less  than  seven  seconds  on  a  sustained 
basis.  This  was  done  without  tuning  the  systems  or  lOMbs  ethemet  components.  We  are 
confident  that  in  phase  II,  the  nature  of  this  notification  can  be  improved  to  achieve  the  "1 ,000 
clients  in  less  than  1  second"  performance  characteristics  expected. 

3. 3. 8  Task  8.  Prototype  the  Entire  Tool  Set 

As  described  in  section  3,  we  have  developed  the  tools  to  receive  notifications  from  the  DCE 
Audit  Service,  and  trigger  alarm  notifications  within  an  existing  Intrusion  Detection  System.  We 
have  developed  the  architecture  and  fundamental  technology  to  consolidate  events  across  a 
diverse  structure  of  centralized  security  servers  to  quickly  identify  "environment-wide"  attacks 
and  a  secure  notification  mechanism  that  can  alert  HUGE  numbers  of  clients  to  appropriately 
respond  to  the  attack.  The  prototyping  we  conducted  actually  created  interfaces  with  both  NIDES 
and  IDIOT  (pre-existing  IDSs  from  outside  sources)  successfully.  We  now  believe  that  it  would 
be  infeasible  to  build  an  eritirely  “false-alann-free"  system  from  the  ground  up.  We  intend  to 
license  components  of  existing  IDSs  (including  independently  developed  rules  etc)  and  compare 
the  results  of  these  IDSs  with  those  of  our  detection  component  (which  monitors  an  entire 
network)  in  order  to  reach  consensus  on  likelihood  of  attack.  By  licensing  previous  R&D  works, 
we  believe  we  can  build  upon  a  huge  accumulated  knowledge  base  and  apply  a  more  pragmatic 
approach  to  reduction  of  false  positives.  “ 

3.3.9  Task  9.  Reporting 

Three  reports  have  been  submitted,  this  being  the  final  report. 
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3.4  Additional  Tasks  Completed  in  Phase  I 

other  than  the  tasks  listed  in  our  original  Phase  I  proposal  we  have  also  performed  two  extra 
tasks: 

1)  Verification/development  of  a  secure  broadcast  RPC  mechanism  to  enable  alarm 
notification  between  alarm_agents  and  alarm_clients. 

2)  Collection  of  source  code  of  other  intrusion  detection  systems  and  integration  of  these 
with  OSF/DCE  intrusion  detection  efforts. 

3)  Collaboration  with  an  external  consultant. 

4)  Obtained  outside  capital  funding  in  support  of  a  Phase  II  ‘Fast  Track"  application. 

5)  Market  and  Competitive  Analysis 

3. 4. 1  Verification  &  Development  of  a  Secure  Broadcast  RPC  Mechanism 

We  proved  that  secure  broadcast  RPC  was  not  a  viable  alarm  channel.  We  investigated  an 
alternative  and  developed  a  secure  direct  (non-broadcast)  RPCs  using  “maybe”  execution 
semantics  which  produced  an  effective  and  secure  multicast  mechanism. 

3. 4.2  Integration  of  Our  DCE-based  Prototype  with  Prior  Intrusion  Detection 
Systems 

We  obtained  source  code  from  SRI  International  for  their  NIDES  product,  from  Purdue  University 
for  their  IDIOT  application,  and  from  U.C.  Davis  for  ExMon  work.  We  have  had  initial  success  in 
integrating  with  both  NIDES  and  IDIOT.  It  appears  likely  that  the  concepts  applied  in  NIDES  and 
IDIOT  can  also  be  applied  to  DCE  (with  the  additional  advantage  that  a  DCE-based  environment 
will  better  support  detection  of  concerted  attacks  and  faster  response).  The  ExMon  application 
was  a  postgraduate  thesis  and  was  not  particularly  well  documented  and  was  therefore  not 
considered  as  valuable  as  the  other  two  products. 

3.4.3  Collaboration  with  an  External  Intrusion  Detection  Consultant 

We  consulted  with  Dr.  Stuart  Staniford-Chen  of  U.C.  Davis.  The  Curriculum  management  team 
believes  that,  in  order  to  bring  an  excellent  commercial  product  to  fruition  in  Phase  II,  the  use  of  a 
well-respected  consultant  in  the  Intrusion  Detection  field  is  essential.  Dr.  Staniford-Chen  was 
chosen  for  his  experience  of  the  Common  Intrusion  Detection  Framework  (CIDF).  It  became 
apparent  from  discussions  with  Dr.  Staniford-Chen  that  CIDF  APIs  could  be  applied  to  our  Phase 
II  effort.  Dr.  Staniford-Chen  has  been  retained  for  extensive  consultation  in  Phase  II. 

3.4.4  Obtained  Outside  Capital  Funding  to  Support  Phase  II  “Fast  Track" 
Application. 

The  company  was  so  pleased  virith  the  potential  for  our  proposed  Phase  II  effort  that  a  number  of 
venture  Capital  firms  and  private  investors  were  approached  with  the  objective  of  obtaining 
matching  capital  in  support  of  a  Phase  II  fast  Track  application  to  DARPA.  This  “SBIR  Fast 
Track"  has,  historically,  funded  over  90%  of  all  applications  (compared  to  35%  or  regular  Phase  II 
applications).  The  Phase  i  results  were  so  compelling  that  company  management  was  prepared 
to  sell  a  proportion  of  the  company  in  order  to  increase  the  chances  of  DARPA  continuing  this 
program! 

In  preparing  our  phase  II  proposal,  much  consideration  was  given  to  achieving  the  significant 
technical  advancements  specified  in  Section  1  within  our  timeframe  and  budget.  Our  Phase  II 
cost  proposal  number  of  $500,198  is  based  upon  our  “fast  track”  application  for  which  we 
obtained  $125,049.50  in  matching  investment  equity  in  support  of  phase  II.  The  $500,198  of 
Phase  II  DARPA  funding  would  provide  3  person-years  of  development  effort.  We  intend  to 
spend  a  large  proportion  of  the  additional  Investor  equity  also  in  support  of  our  technical  goals 
(thereby  adding  another  person-year  of  development  effort).  If  we  find  that  additional  resources 
are  required,  the  company  Is  prepared  to  re-invest  up  to  $200,000  of  our  earnings  (from 
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commercial  operations)  over  the  22  month  period  to  ensure  success  for  a  project  that  we  believe 
has  a  huge  commercial  market. 

3. 4. 5  Market  and  Competitive  Analysis 

There  were  three  main  factors  in  determining  whether  Curriculum  Corporation  should  apply  for 
continuance  of  this  work  into  Phases  II  and  III.  These  factors  were: 

1)  Is  the  idea  conceived  of  in  our  Phase  I  application  achievable? 

2)  Is  there  a  market  for  this  product? 

3)  Is  this  product  unique  enough  to  command  a  significant  market  share? 

The  results  of  these  analyses  follow. 

3.4.5.1  Is  this  idea  achievable? 

The  technical  challenges  to  a  robust  Intrusion  Detection  System  that  generates  low  false  alarm 
rates  are  significant.  Our  research  in  Phase  I  indicates  that  this  problem,  though  significant  is  not 
insoluble.  We  believe  that  by  making  use  of  an  existing  framework  (DCE)  and  some  existing  IDS 
components  we  can  develop  the  product  envisaged  in  our  original  Phase  I  application. 

3.4.5.2  Is  there  a  market  for  this  product? 

Our  almost  one  million  dollars  of  DCE>related  sales  in  1997  indicate  the  company’s  ability  to 
market  our  existing  products. 

The  widespread  implementation  of  Microsoft’s  COM  and  ActiveX  technologies  (as  bundled  with 
Windows  95  and  NT)  provides  a  huge  market  where  DCE-compatible  systems  are  already  in 
place.  The  upcoming  release  of  Active  Directory  with  Windows  NT  version  5  implements  a  DCE- 
like  centralized  security  registry  and  directory  service.  These  Microsoft  technologies  use  DCE- 
compatible  Remote  Procedure  Calls  (RPCs)  already.  It  is  a  simple  matter  for  security-conscious 
sites  running  NT  and  Win95  to  implement  a  DCE  cell  and  centralize  all  password  and  security 
requests  at  the  central  security  service.  In  this  kind  of  environment,  the  proposed  product  would 
be  a  natur^al  fit.  DCE  today,  however,  is  more  commonly  seen  in  enterprise-wide  applications 
linking  mainframes,  midrange  systems,  and  desktops  together.  Here  the  true  benefits  of  the 
proposed  product  will  lie.  Every  intrusion  into  an  enterprise  has  the  potential  to  affect  every 
systenri  connected  by  a  network.  It  therefore  only  makes  sense  to  implement  an  Intrusion 
Detection  and  Response  tool  that  executes  on  EVERY  platfonn  in  an  enterprise,  from  the  desktop 
to  the  mainframe.  Our  research  involved  discussion  to  a  number  of  our  security-conscious 
fortune  500  customers  who  today  do  not  make  use  of  an  Intrusion  Detection  System.  It  became 
clear  that  our  customers  see  far  less  value  in  an  ID  solution  that  is  tied  to  only  one  operating 
system.  Our  heterogeneous  solution  had  far  more  appeal  (especially  to  very  large  sites). 

A  brief  list  of  only  a  selection  of  Curriculum  Corporation’s  current  customers  who  are  prime 
candidates  for  initial  site-licerise  sales  of  the  proposed  product  includes:  Bellcore,  Boeing, 
Computer  Sciences  Corporation,  Citicorp,  DEC,  Environmental  Protection  Agency,  Honda 
America,  IBM,  Intel,  Lexis-Nexis  Corporation,  Pacific  Bell,  T.  Rowe  Price. 

From  the  list  above  it  should  be  clear  that  our  established  customer  base  is  made  up  almost 
exclusively  of  Fortune  500  customers  who  care  deeply  about  enterprise-wide  computer  security. 
We  believe  that  we  can  leverage  our  existing  relationships  with  each  of  these  companies  to  build 
up  initial  sales  momentum.  With  successful  implementations  installed  at  these  premiere  sites, 
sales  to  a  wider  customer  base  should  be  easier.  One  of  the  hardest  tasks  faced  by  Cumculum 
Corporation  in  its  first  years  of  business  was  gaining  credibility  in  the  computer  security 
marketplace.  With  this  behind  us,  we  feel  that  we  now  are  well  placed  to  exploit  a  huge 
underdeveloped  market  for  a  quality  commercial  (enterprise-wide)  Intrusion  Detection  System. 

The  DCE  (enterprise  security)  marketplace  in  which  Curriculum  Corporation  operates  is,  in  1997, 
a  200  million  dollar  market.  The  largest  player  in  this  market.  Transarc  Corporation  (a  subsidiary 
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of  IBM),  holds  around  one  third  of  this  market  (with  estimated  1997  sales  of  72  million  dollars). 
The  market  appears  to  have  grown  by  60%  from  1996  (based  on  Transarc’s  1996  sales  of  45 
million  dollars  and  constant  market  share  -  as  reported  by  the  Gartner  Group).  A  conservative 
measure  for  the  1999  DCE  market  size  would  therefore  be  512  million  dollars  (based  upon  a 
constant  growth  rate  of  60%  over  two  years).  Given  that  our  proposed  tool  is  applicabie  to  DCE 
based  or  NT  Domain  Controller  based  environments,  it  is  reasonabie  to  assume  that  the  market 
for  security  tools  in  either  of  these  environments  will  be  at  least  double  that  of  the  DCE  security 
marketplace,  or  in  other  words,  around  one  billion  dollars  in  1999.  Since  commercial  Intrusion 
Detection  Systems  have  been  few  and  relatively  unused  to  date,  it  is  hard  to  predict  what 
percentage  of  the  computer  security  marketplace  they  may  hold  by  1999.  A  very  conservative 
figure  would  be  three  percent  of  a  one  billion  dollar  market  or  about  30  million  dollars. 

During  the  last  six  months  of  a  Phase  II  development  effort.  Curriculum  intends  to  hire  a 
marketing  and  sales  manager  solely  dedicated  to  the  proposed  product  (funds  provided  by  our 
company). 

3.4.5.3  Is  this  product  unique  enough  to  command  market  share? 

other  companies  selling  Intrusion  Detection  Systems  include:  Intrusion  Detection  Inc  (Kane 
Security  Monitor),  Haystack  Labs  (Stalker),  Bellcore/SAIC  (CMDS),  Digital  Equipment 
Corporation  (Polycenter  Intrusion  Detector),  INTRINsec  Corp,  Trusted  Systems  Inc,  Oddysey 
Research  Associates,  Wheel  Group  (NetRanger). 

We  shall  differentiate  the  proposed  Phase  II  product  through  the  fact  that  it  operates  across  the 
entire  enterprise  (across  many  operating  systems).  This,  we  believe,  is  a  crucial  differentiation 
that  our  competitors  will  not  be  able  to  match.  In  order  to  achieve  this  heterogeneity,  our  product 
must  operate  in  an  environment  supporting  a  centralized  security  service.  We  believe  that  the 
use  of  either  DCE  or  NT5.0  Domain  Controllers  as  that  security  service  gives  us  access  to  almost 
all  computers  in  an  enterprise  (from  NT  workstation  &  Windows  95  clients  to  MVS  at  the  upper 
end). 

3.5  Background  Research  and  Preparation 

In  order  to  develop  a  suitable  prototype  intrusion  detection  system,  a  study  of  previous  research 
and  works  was  conducted  as  well  as  basic  platform  preparation  to  conduct  development  testing 
and  prototyping  upon. 

3. 5. 1  Literary  Research 

In  the  original  proposal,  a  list  of  references  was  identified.  As  the  research  effort  evolved,  this  list 
grew  and  a  representative  list  of  works  are  illustrated  in  the  Bibliography  at  the  end  of  this  report. 

3.5. 1.1  An  Introduction  to  Intrusion  Detection 

Intrusions  can  be  generically  divided  into  six  categories  [1,2]: 

-  Attempted  break-ins,  which  are  detected  by  atypical  behavior  profiles  or  violations  of 
security  constraints. 

Masquerade  attacks,  which  are  detected  by  atypical  behavior  profiles  or  violations  of 
security  constraints. 

-  Penetration  of  the  security  control  system,  which  are  detected  by  monitoring  for 
specific  patterns  of  activity. 

Leakage,  which  is  detected  by  atypical  use  of  system  resources. 

Denial  of  service,  which  is  detected  by  atypical  use  of  system  resources. 

-  Malicious  use,  which  is  detected  by  atypical  behavior  profiles,  violations  of  security 
constraints,  or  use  of  special  privileges. 

The  basic  classes  of  intrusion  detection  systems  include  anomaly  detection  systems  and  misuse 
detection  systems.  Anomaly  detection  systems  often  employ  one  or  more  methods  to  identify 
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anomalies.  Methods  such  as  statistical  methods,  predictive  pattern  methods,  and  possibly  neural 
network  rnethods  are  common.  Misuse  detection  systems  often  approach  the  problem  by  using 
technologies  such  as  expert  system  methods,  keystroke  monitoring  methods,  model-based 
methods,  state  transition  methods,  and  possibly  pattern  matching  methods.  There  are  still  other 
intrusion  detection  systems  that  use  techniques  like  "generic  model"  methods,  network  traffic 
monitoring  methods,  and  possibly  various  distributed  methods  using  "autonomous  agents". 

Several  issues  continue  to  plague  developing  solutions  to  the  problem; 

-  Monitoring/response  system  overhead  -  can  cost  more  than  it  is  worth 

-  False  identifications  (non-intrusive  activity  identified  as  intrusive,  or  intrusive  activity 
not  identified  as  such)  which  is  sometimes  referred  to  as  the  signal-to-noise  ratio 
Data  sources  -  are  the  necessary  audit  events  being  provided  by  the  subjects  and 
are  they  in  a  form  usable  by  an  intrusion  detection  system 

-  Response  techniques  -  what  is  appropriate  and  how  do  you  effect  the  action 

3.5. 1.2  Next-Generation  Intrusion  Detection  Expert  System  (NIDES) 

A  mature  intrusion  detection  system  has  been  developed  since  the  late  1980s  at  the  Computer 
Sciences  Laboratory  of  SRI  International  [3,4,5].  Originally  developed  as  the  Intrusion  Detection 
Expert  Systems  (IDES)  it  evolved  into  NIDES  in  the  mid-1990s.  This  system  contains  well 
developed  rule-based  expert  system  and  statistical  components.  These  components  combine 
together  to  determine  if  an  event  is  intrusive  or  not.  This  system  also  includes  effective  graphical 
user  interfaces,  testing  of  potential  rulesets,  and  other  facilities  which  make  the  system  usable  in 
a  "real  world". 

3.5. 1.3  Intrusion  Detection  In  Our  Time  (IDIOT) 

As  a  graduate  student  project  at  Purdue  University,  Sandeep  Kumar  and  other  COAST  students 
developed  an  intrusion  detection  system  with  the  acronym  IDIOT  [6].  Sandeep's  design  made 
use  of  a  new  classification  of  intrusion  methods  based  on  complexity  of  matching  and  temporal 
characteristics.  He  also  designed  a  generic  matching  engine  based  on  colored  Petri  nets. 

3. 5. 2  Product  Research 

A  study  of  the  current  research  efforts  and  market  place  was  conducted  to  determine  the 
solutions  available  in  the  summer  of  1997.  This  was  done  to  learn  what  benefits  and  deficiencies 
each  product  has. 

Several  commerdal  products  were  investigated  but  since  this  effort  was  a  research  effort,  a  focus 
freely  available  software  that  existed  already.  We  obtained  source  versions  of  the 
!k  systems.  These  two  systems  were  studied  and  an  interface  developed  such 

that  DCE  based  audit  events  could  trigger  intrusion  alerts  in  each  system.  This  effectively  proves 
could  interface  DCE  related  events  with  a  good  portion  of  existing  systems  without 
significant  rewrite  of  the  existing  systems. 

3. 5. 3  Organizational  Research 

Since  computer  system  security  is  a  focused  discipline  and  intrusion  detection  even  more  narrow 
within  that  discipline,  there  naturally  occurs  to  be  a  relatively  small  group  of  organizations  and 
individuals  who  constitute  the  "state-of-the-art"  knowledge  base.  A  study  of  these  organizations 
was  conducted  to  detemnine  who  would  be  of  benefit  to  this  research  effort. 

We  found  several  groups  with  significant  histories  of  intrusion  detection  activity  Most  notable 
groups  include: 

-  Defense  Advanced  Research  Projects  Agency  (DARPA)  Information  Technology 
Office  (ITO),  Arlington,  VA 

-  Computer  Science  Laboratory  (CSL)  of  SRI  International  in  Menlo  Park,  CA 
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Computer  Operations,  Audit,  and  Security  Technology  (COAST)  Project  of  the 
Computer  Science  Department  of  Purdue  University,  West  Lafayette,  IN 
-  Computer  Security  Research  Laboratory,  Department  of  Computer  Science 
University  of  California,  Davis,  CA 

We  made  contacts  with  each  of  these  organizations  and  attended  conferences  as  necessary  to 
understand  the  existing  groups.  Relationships  were  developed  with  selected  parties  to  aid  in  the 
interim  and  subsequent  phases  of  the  overall  project. 

3.5.4  Preparation 

As  discussed  in  the  original  proposal.  Curriculum  Corporation  has  resources  ready  to  be  used  in 
the  conduct  of  this  research.  However  specific  resources  were  required  to  actually  build  and  test 
prototype  architectures.  These  were  systems  running 

Sun  Microsystems  (SUN):  Solaris  2.5.1  and  SunOS  4.1.3 
International  Business  Machines  (IBM):  AIX  4.1.4  and  AIX  4.2 
Microsoft  (MS):  Windows  NT  Server  4.0,  Windows  95 
Hewlett-Packard  (HP):  HP-UX  10.10 

Any  potential  Intrusion  Detection  System  solution  was  expected  to  audit  all  of  these  environments 
as  well  as  IBM/MVS. 

3.6  Principal  Areas  of  Investigation 

In  Older  to  develop  a  commerdal  grade  intrusion  detection  system  using  the  Open  Software 
Foundation  (OSF)  Distributed  Computing  Environment  (DCE),  several  technological  strengths 
were  investigated. 

3. 6. 1  Use  of  the  DCE  Audit  Service  as  a  source  of  Data  for  Intrusion  Detection 

With  OSF/DCE  Version  1.1,  a  new  audit  service  was  introduced.  This  audit  service  provided  an 
Application  Programming  Interface  (API)  for  DCE  based  applications  to  use  such  that  events 
could  be  recorded  by  the  audit  service.  The  audit  service  adds  routine  pieces  of  information  and 
maintains  the  control  of  the  storage  of  the  events. 

This  service  as  presently  constituted  in  DCE  1.1,  which  vendors  (e.g.  IBM,  HP)  have  been 
shipping  since  late  1995,  is  the  predecessor  technology  to  the  X/Open  Distributed  Audit 
System  (XDAS)  which  is  currently  evolving  [7].  We  fully  expect  the  OSF/DCE  Audit  Service  to 
keep  pace  with  the  XDAS  specification  and  thus  our  use  of  this  current  service  enables  us  to 
maintain  currency  without  significant  rework/change  in  the  intrusion  detection  system. 

The  DCE  Audit  service  is  capable  of  being  used  in  either  of  two  main  ways: 

1)  As  a  means  of  detecting  user-defined  events  in  a  user-written  application. 

2)  As  a  means  of  detecting  any  security  interaction  between  a  client  computer  and  the 
Kerberos  V  security  server  that  serves  it.  Distributed  security  systems  implementing  a 
centralized  Kerberos  server  are  DCE  and  NT  5.0  Domain  Controllers 

The  latter  of  these  approaches  is  used  by  Curriculum  Corporation  in  this  project. 

The  system  structure  of  the  DCE  Audit  Service  is  based  on  a  client/server  approach  within  the 
confines  of  a  single  operating  system  image.  An  administrative  interface  is  provided  as  a  subset 
of  the  control  program  for  DCE.  The  audit  service  makes  full  use  of  the  DCE  Security  Service  to 
protect  itself  against  unauthorized  access. 
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On  each  system  where  the  DCE  Audit  Service  is  to  be  used,  a  long  running  process  called  auditd 
will  be  started  as  part  of  the  DCE  startup.  This  auditd  process  manages  the  recording  of  data 
and  filters  used  to  limit  the  data  being  recorded.  The  filters  are  used  in  conjunction  with  event 
classes  which  group  specific  audit  events. 

Each  audit  client  defines  what  events  are  to  audited  by  making  calls  to  the  audit  application 
programming  interface  (API)  at  the  desired  code  points.  Audit  events  are  identified  by  an  event 
number  which  is  a  32  bit  integer.  Event  numbers  are  a  tuple  made  up  of  the  set-id  and  event-id 
thus  segmenting  the  address  space  for  effective  management  across  multiple  development 
groups.  These  event  numbers  are  then  equated  to  symbolic  names  within  the  client  program  to 
document  the  purpose  for  that  event  number.  A  generic  example  might  be: 

/*  Audit  event  nunibers  OxcOOOOOOO  through  OxcOOOOOff  are  enployee  events.  ♦/ 
#define  audit_event_query_eitployee  OxcOOOOOOO 

#deflne  audlt^event^add^enployee  OxcOOOOOOl 

#deflne  aud±t_event__inodify_enployee  0xc0000002 

#deflne  audit^event_^delete_exnployee  0xc0000003 

These  event  numbers  are  then  grouped  into  event  classes  for  effective  filtering  of  events.  The 
event  classes,  which  are  numbered  also,  can  be  supersets  of  the  specific  events.  Example: 

/*  Audit  event  nuitibers  OxcOOOOOOO  through  OxcOOOOOff  are  enployee  events.  */ 

/*  Audit  event  nuna>ers  OxcOOOOlOO  through  OxcOOOOlff  are  payroll  events.  */ 

/*  Audit  event  nuiribers  0xc0000200  through  0xc00002ff  are  calendar  events.  */ 

query_^events 

OxcOOOOOOO  #audit_event_query  enployee 

OxcOOOOlOO  #audit__event_query3>ayroll 

0xc0000200  #audit_event^query  calendar 

add_events 

OxcOOOOOOl  #audit_event_add_enployee 

OxcOOOOlOl  #audit_event_add_payroll 

0xc0000201  #audit_event_add_calendar 

update_events 

OxcOOOOOOl  #auditjevent_add_eitployee 

OxcOOOOlOl  #audit_event__add_j>ayroll 

0xc0000201  #audit  event  add  calendar 
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OXC0000002 
0XC0000102 
0XC0000202 
OXC0000003 
OxcOOOOlOS 
0XC0000203 

delete_event3 

0XC0000003 
0XC0000103 
0XC0000203 

Once  event  classes  are  created  and  accessible  by  the  auditd  process,  the  audit  administrator  can 
then  invoke  filtering  policies  based  on  the  event  classes.  Example: 

audf liter  create  {group  enployees}  -attribute  {add_events  failure  log) 
audfllter  create  {group  enployees}  -attribute  {delete^events  success  log} 
audfllter  create  {group  etnployees}  -attribute  {xnodlfy^events  denial  {log  alarm)} 
audfllter  create  {principal  guest}  -attrlb  { { query^events  inodlfy__events}  all  log} 


#audlt_event_modlfy_einployee 
#audlt^event^modlfy_payroll 
#  audl  t_event_jnodl  f y^cal  endar 
#audlt_event_delete_employee 
#audlt_event_delete_payroll 
#audlt  event  delete  calendar 


#audlt^event_^delete_enployee 
#audlt^event^delete_payroll 
#audlt  event  delete  calendar 


When  audit  filter  updates  are  communicated  to  the  auditd  process,  auditd  notifies  the  audit  ciients 
that  a  change  has  occurred  so  the  API  runtime  can  refresh  the  in-memory  filter  table.  In  this  way, 
filtering  is  done  at  the  lowest  possible  level,  is  efficient,  and  can  be  dynamicaily  updated  with  a 
consistent  user  interface  at  a  very  granular  level. 

3.6. 1 . 1  Reading  of  the  Audit  Logs 

As  applications  call  the  audit  service  API  to  record  events,  the  audit  service  saves  these  events  in 
the  form  of  records  within  an  audit  log  maintained  on  a  disk  resident  filesystem.  These  audit  logs 
are  maintained  on  the  system  local  to  the  application  generating  the  event.  The  audit  service 
additionally  provides  API  calls  to  read  the  audit  logs. 

In  order  for  an  intrusion  detection  system  to  operate  in  a  near  real-time  mode,  the  system  must 
receive  event  information  as  it  happens.  As  systems  get  larger  and  activity  increases,  the 
number  of  events  escalates  rapidly.  It  is  not  uncommon  for  commercial  mainframe  operating 
systems  in  use  today  to  generate  many  millions  of  events  in  a  24  hour  period  •  on  a  single 
system.  As  computer  use  grows,  these  single  systems  combine  into  an  interwoven  network  of 
distributed  systems  each  with  strengths  and  weaknesses.  Thus  intrusion  detection  systems  must 
be  able  to: 

1)  Examine  audit  events  as  they  occur, 

2)  Consolidate  audit  events  across  multiple  systems  separated  by  a  network  layer, 

3)  Be  able  to  handle  very  large  volumes  of  events  without  being  overwhelmed,  and 

4)  Not  be  such  a  burden  to  the  system  that  the  primary  purpose  of  the  system  is  significantly 
hindered. 

Our  architecture  calls  for  two  layers  of  Intrusion  Detection  engines: 

1)  A  detection  engine  reading  the  audit  trail  of  a  centralized  DCE  or  NT  security  server,  and 

2)  A  lightweight  detection  engine  reading  the  audit  trail  of  clients. 

The  first  detection  engine  is  intended  to  detect  a  varied  array  of  events  and  is  therefore  not 
lightweight.  It  runs  on  a  specialized  server  with  hardware  designed  to  deal  with  a  significant  load. 

The  second  detection  engine  detects  only  those  patterns  that  are  invisible  to  the  centralized 
security  server  (e.g.  illicit  use  of  Unix  setuid  files).  The  limited  scope  of  this  client  detection  engine 
allows  a  lightweight  implementation.  Meaningful  performance  tests  are  not  possible  until  a  more 
production-oriented  client  is  built. 

3.6.1. 1.1  Using  the  Audit  Service  API  to  Monitor  Incoming  Events 
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An  early  part  of  our  research  involved  determining  how  to  effectively  read  the  audit  events  as  they 
happen  in  an  efficient  manner.  Programs  were  written  using  the  OSF/DCE  Audit  Service  APi  to 
read  the  various  audit  logs  used  by  the  Audit  Service. 

To  perform  this  function,  we  developed  a  test  program  called  auditListen  which  runs  in  the 
background  and  does  the  following; 

1)  Opens  the  audit  trail  using  the  dce_aud_open  ( )  API 

2)  Reads  all  records  from  the  trail  until  receiving  a  NULL  using  the  dce  aud  next  ( )  API 

and  writes  them  to  an  external  log  file  “ 

3)  Waits  until  new  record(s)  is/are  written  to  the  audit  trail 

4)  When  a  new  record  is  sensed,  it  reads  the  record(s)  from  the  end  of  the  audit  trail  using 
the  dce_aud_next  ( )  API  and  appends  them  to  the  external  log 

5)  goto  (3) 

We  discovered  that  after  auditListen  opened  the  file  using  dce_aud_open  ( )  and  read  all  the 
records  using  dce_aud_next  ( ) ,  it  could  never  "see"  any  more  updates  to  the  file.  It  turns  out 
that  when  you  use  dce_aud_next  ( )  and  read  until  you  get  until  the  NULL,  you  never  are  able 
to  see  anything  else  added  to  the  end  of  the  file.  ie.  the  next  record  from  a  NULL  is,  well,  NULL. 

We  developed  a  new  function  within  auditListen  called  dce  aud  backup  ( )  which  decrements 
the  current  audit  record  position  pointer  a  specified  amount,  in  this  case,  1  record.  Therefore,  the 
new  version  functions  as  follows: 

1)  Opens  the  audit  trail  using  the  dce  aud  open  ( )  API 

2)  Reads  all  records  from  the  trail  until  receiving  a  NULL  using  the  dce_aud_next  ( )  API 

and  writes  them  to  an  external  log  file  “ 

3)  Call  dce_aud_backup  ( )  to  backup  to  the  last  record  and  NOT  the  NULL  pointer 

4)  Waits  until  new  record(s)  is/are  written  to  the  audit  trail 

5)  When  a  new  record  is  sensed,  it  reads  the  record(s)  from  the  end  of  the  audit  trail  using 
the  dce_aud_next  ( )  APi  and  appends  them  to  the  external  log 

6)  goto  (3) 

This  seemed  to  work  under  normal  circumstances,  but  still  two  problems  existed: 

1)  What  happens  when  audit  trail  reached  max  size  and  rolls  over? 

2)  What  happens  when  someone  rewinds  the  point  at  which  events  are  logged? 

The  DCE  Audit  Service  allows  the  log  file  to  be  managed  in  several  ways.  The  default  condition 
is  to  write  to  the  log  file  until  the  value  specified  in  the  DCEAUTDITTRAILSIZE  environment 
variable  is  attained,  then  logging  is  stopped.  Alternatively,  if  the  "wrap"  option  is  used,  once  the 
maximum  size  has  been  achieved,  auditd  repositions  the  "next  record"  pointer  to  the  beginning  of 
the  file  thus  rewriting  over  the  file  in  a  wrapping  manner.  Additionally,  at  any  time,  an  audit 
administrator  can  "rewind"  the  log  file  via  a  command  to  auditd  thus  repositioning  the  "next 
record"  pointer  to  be  the  beginning  of  the  log  file  in  effect  manually  evoking  the  wrapping  function. 

In  each  case,  auditListen  needed  to  sense  this,  close  the  audit  trail  file  using  the 
dce_aud_close  ( )  API  and  reopen  it.  Without  this,  auditListen’s  "next  record  position"  in  the  file 
would  not  coincide  with  auditd's  current  record  position.  Since  these  conditions  do  not  happen 
with  great  frequency,  closing  and  opening  the  file  does  not  add  that  much  overhead  and  is  a 
reasonable  solution.  auditListen  was  modified  to  do  this  so  now  it  performs  the  desired  function 
using  the  standard  DCE  Audit  Service  APIs. 

[See  Appendix  A  for  related  source  code] 

3.6.1. 1.2  Consolidating  Audit  Service  Events  Across  Multiple  Systems 

Since  the  audit  service  records  events  only  on  the  system  upon  which  it  runs,  filtering  and 
forwarding  these  events  into  a  central  repository  was  needed  to  get  a  "overall  view"  of  the  entire 
distributed  system. 
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Once  auditListen  was  written,  the  next  step  was  to  develop  a  multi-system  audit  log  consolidation 
methodology  such  that  a  "single  system  image"  could  be  represented.  While  DCE  offers  great 
benefits  In  that  the  DCE  Security  Service  is  a  centralized  function,  there  is  still  need  to 
consolidate  audit  data  when  the  DCE  Security  Service  is  replicated  on  multiple  systems.  Further, 
should  an  activity  wish  to  develop  their  own  audit  events  for  inclusion  in  the  intrusion  detection 
system,  an  architecture  was  needed  to  "see  what  was  going  on"  across  multiple  systems. 

Using  the  DCE  Directory  Services,  in  conjunction  with  the  Remote  Procedure  Call  (RPC)  and 
Security  Services,  an  architecture  was  developed  that  allows  granular  control  of  the  consolidation 
and  failure/backup  recovery  mechanisms.  A  new  process,  auditCentral,  serves  as  a  collector  of 
audit  log  data  forwarded  from  one  or  more  auditListen  processes.  The  auditCentral  server 
publishes  its  interface  in  the  DCE  Directory  Service  using  a  Name  Service  Interface  (NSI)  Profile 
Entry  and  a  NSI  Server  Entry.  This  allows  the  auditListen  clients  to  locate  multiple  collection 
servers  in  a  prioritized  manner.  The  use  of  the  Directory  Service  also  allows  servers  to  be  added 
and  deleted  to  the  configuration  without  system  disruption.  Use  of  the  prioritization  inherent  with 
the  NSI  Profile  Entry,  allows  a  controlled  distribution  of  data  collection  as  necessary. 
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Figure  2  The  auditCentral  Architecture 

Each  auditListen  client  uses  secure  RPC  APIs  to  forward  audit  log  data  to  the  auditCentral 
server.  If  for  some  reason  the  primary  server  fails  to  respond,  the  auditListen  clients 
automatically  start  forwarding  the  data  to  the  backup  server.  When  the  primary  is  available  again, 
the  backup  notifies  the  clients  to  relocate  the  primary. 

This  architecture  has  yet  to  be  developed,  but  since  this  is  a  natural  DCE  based  client/server 
structure  that  we  have  developed  previously,  we  have  total  confidence  the  structure  will  work  with 
good  success  and  performance. 

3.6.1. 1.3  Making  Sense  of  the  Audit  Records 

Since  DCE  1 .1  leaves  it  up  to  the  application  writer  to  determine  what  events  should  be  audited,  a 
study  of  what  events  the  DCE  Security  Service  and  Audit  Service  record  was  needed.  The  code 
points  chosen  by  the  OSF/DCE  development  staff  are  in  effect  static  as  they  are  compiled  into 
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the  DCE  core  programs  -  none  can  be  added  or  modified.  With  the  use  of  audit  filters,  the  audit 
administrator  can  effectiveiy  ignore  any  of  the  existing  code  points. 


The  below  list  shows  the  discrete  events  coded  in  the  DCE  Security  and  Audit  services.  Included 
in  the  listing  are:  1)  the  symbolic  name  for  the  event,  2)  event  number  (hexadecimal  and 
decimal),  and  3)  one  or  more  default  event  classes  within  which  that  event  is  defined  and  the 
corresponding  event  class  number  for  that  event  class. 


DCE  SECURITY  SERVICES  EVENTS 


EVENT  SYMBOLIC  NAME 

AS^Request 

TGS_Ti  eke  tReq 

TGS^RenewReq 

TGS_ValidateReq 

ACL^IiOokup 

ACL_Replace 

ACL^^GetAccess 

ACL^TestAccess 

ACL^Tes tOnBehal f 

ACL_GetMgrTypes 

ACL_GetReferral 

PRIV_GetPtgt 

ACCT_Add 

ACCT_Delete 

ACCT^Rename 

ACCT__Lookup 

ACCT_J^^lace 

ACCT_GetPro j lis t 

LOGIN_GetInfo 

PGO_Add 

PGO__Delete 

PGO_R^lace 

PGO_Renaxne 

PGO_Get 

PGO_JCeyTransfer 

PGO_AddMeinber 

PGO_DeleteMeinber 

PGO^I  sMeiriber 

PGO_GetMeinbers 

PROP_GetInfo 

PROP__SetInfo 

POLICY_GetInfo 

POLICY_SetInfo 

AUTHPOLICY_GetInfo 

AUTHPOLICY_SetInfo 

REPADMIN_Stqp 

REPADMIN_Maint 

{dce^sec^server  14  > 

REPADMIN_Mkey 

REPADMI N_pes t r oy 

REPADMIN_Init 

ERA_Update 

ERAJDelete 

ERA^Testl^date 

ERA_LookupBy I d 

£RA^LookupNoE3q>and 

ERA^LookupByName 

ERA^^SchemaCreate 

ERA__SchemaDelete 

ERA^SchemaUpdate 

ERA_SchemaLookupI  d 

ERA^SchemaLookupName 

PRiy_GetEptgt 

PRIV_RdlgTokInfo 

PRiyjBecomeDel  ega  te 

PRiy_BecoineIiipersonator 


EVENT  NUMB  { EVENT_CLASS__NAME  EVENT_CLASS_NUMBER} 
0x0101  257  {dce_sec_authent  10} 

0x0102  25B  {dce_sec_authent  10) 

0x0103  259  {dce^sec^authent  10) 

0x0104  260  {dce_sec_authent  10) 

0x0105  261  {dce^sec^control  12)  { dce^sec^cpiery  13} 

0x0106  262  {dce_sec_control  12}  {dce_sec_niodlfy  11} 

0x0107  263  {dce_sec_control  12}  {dce_sec_query  13} 

0x0108  264  {dce_sec_control  12}  {dce_sec_query  13} 

0x0109  265  {dce^sec^control  12}  <dce  sec_query  13} 

0x01  OA  266  {dce_sec_control  12}  {dce_sec_query  13} 

OxOlOB  267  {dce_sec_control  12}  (dce^sec  query  13} 

OxOlOC  268  {dce_sec_authent  10}  {dce^sec  control  12} 
OxOlOD  269  {dce__sec_control  12}  {dce^sec^nodify  11} 
OxOlOE  270  {dce_sec_control  12}  {dce^sec^modify  11} 
OxOlOF  271  {dce_sec_control  12}  (dce_sec__modify  11} 
0x0110  272  {dce_sec_control  12}  {dce_sec_^query  13} 
0x0111  273  {dce_sec_control  12}  {dce^sec^nodify  11} 
0x0112  274  {dce_^sec_control  12}  {dce_sec_ciuery  13} 
0x0113  275  { dce^sec^control  12}  {dce_sec_query  13} 
0x0114  276  {dce_^sec__control  12}  {dce^sec  inodify  11} 
0x0115  277  {dce_sec_control  12}  {dee  sec^modify  11} 
0x0116  278  {dce__sec_control  12}  {dce_sec_niodify  11} 
0x0117  279  {dce_sec_^control  12}  {dce__sec  modify  11} 
0x0118  280  {dce__sec_control  12}  {dee  sec  query  13} 
0x0119  281  {dce_sec__control  12}  ” 

OxOllA  282  {dce_sec_control  12}  {dce_sec_jnodify  11} 
OxOllB  283  { dce_sec_control  12}  {dce_sec_modify  11} 
OxOllC  284  { dce__sec_control  12}  {dee  sec  query  13} 
0x01  ID  285  {dce_sec_control  12}  {dce^sec^juery  13} 
0x01  IE  286  { dce^sec^control  12}  {dce__sec  query  13} 
OxOllF  287  {dce_sec_control  12}  {dce^sec^nodify  11} 
0x0120  288  { dce_sec_control  12}  {dee  sec  query  13} 
0x0121  289  {dce_sec_control  12}  {dce^sec^modify  11} 
0x0122  290  {dce_sec_control  12}  { dce_sec_query  13} 
0x0123  291  {dce_sec_control  12}  { dce_sec_niodif y  11} 
0x0124  292  {dce^sec_^control  12}  {dce__sec  server  14} 
0x0125  293  {dce^sec^authent  10}  { dce^sec~control  12} 

0x0126  294  { dce__sec^control  12}  {dee  sec  server  14} 

0x0127  295  {dce^sec_^control  12}  {dee  sec  server  14} 

0x0128  296  { dce_sec_control  12}  {dce_^sec  server  14} 
0x01 2B  299  {dce_sec_control  12}  {dce^sec^nodify  11} 
0x012C  300  {dce_sec_control  12}  {dce_sec_inodify  11} 
0x01 2D  301  { dce_sec__control  12}  {dce__sec  c[uery  13} 

0x012E  302  { dce^sec^control  12}  {dee  sec  query  13} 

0x01 2F  303  {dce_sec_control  12}  {dce_sec__query  13} 
0x0130  304  {dce_sec_control  12}  { dce_sec~query  13} 
0x0131  305  {dce_sec_control  12}  { dce_sec_inod±f y  11} 
0x0132  306  {dce_sec_control  12}  {dee^seejmodify  11} 
0x0133  307  {dce_sec_control  12}  {dce^sec^modify  11} 
0x0134  308  { dce^sec^control  12}  {dce__sec  query  13} 
0x0135  309  { dce^sec_control  12}  {dee  sec  query  13} 
0x0136  310  {dce__sec_authent  10}  { dce_sec~control  12} 
0x0137  311  {dce__sec^authent  10} 

0x0138  312  {dce_sec_authent  10}  { dce_sec_control  12} 
0x0139  313  {dce_sec__authent  10}  { dce_sec_contr ol  12} 


AUDIT  SERVICE  EVENTS 
delete  filter 


0x300  768  {dce_audit_filter_inodify  0x30} 
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list  filter 

0x302 

770 

add  filter 

0x303 

771 

remove  filter 

0x304 

772 

modify  sstrategy 

0x305 

773 

modify  state 

0x306 

774 

rewind 

0x307 

775 

stop 

0x308 

776 

show  sstrategy 

0x309 

777 

show  state 

0x30a 

778 

{  dce_audit__f il ter^qaery  0x31 } 

( dce_audit__f ilterjnodify  0x30 ) 
{dce^audit^filterjmodify  0x30} 
{ dce^audi t_admin_jnodif y  0x32  } 

{ dce^audi t^adminjmodify  0x32 > 
{dce_audit_adinin__modify  0x32} 
{dce_audit__admirwnodify  0x32} 
<dce_audit_adinln_query  0x33} 
{dce_^audit_adininjiuery  0x33} 


Each  audit  event  may  add  additional  event  specific  infomiation  to  the  tail  of  the  audit  record.  For 
example,  the  ACL_Replace  (0x106)  event  adds: 


char 

uuid^t 

sec^aud__type_t 
sec^acl__l  i  s  t^t 
sec  acl  list  t 


*  conponen  t^name 
manager^type 
acl_type 
old_acl_list 
new  acl  list 


In  this  way,  the  audit  record  can  contain  as  much  data  as  the  code  point  would  offer.  In  this 
example,  you  would  know  who  changed  what  when. 

Our  investigations  have  shown  that  not  every  well-known  UNIX  or  NT  intrusion  will  generate  an 
event  at  a  centralized  security  server.  Those  intrusions  that  are  “invisible”  to  this  centralized 
location  can  be  programmed  as  rules  to  our  local  (lightweight)  detection  engine. 


3.6.1. 1.4  Filtering  Out  the  Noise 

The  Phase  I  tests  conducted  showed  that  audit  events  can  be  easily  filtered  such  that  only  the 
"interesting"  events  are  actually  recorded  in  the  audit  logs.  This  is  done  through  the  use  of  event 
classes  which  can  be  dynamically  added/changed/deleted  within  an  running  system.  This 
“upstream"  filtering  reduces  the  CPU  overhead  associated  with  our  detection  engines. 


Filters  allow  discrete  events  to  be  handled  in  specific  ways  for  specific  resources.  Audit  filters  are 
applied  with  a  filter  name  which  incorporates  the  DCE  Registry  identity  as  follows: 


principal 
foreign_princlpal 
group 

foreign_group 

cell 

cell_overridable 

world 

world  overridable 


keyed  with  local  DCE  cell  principal  (user)  name 
keyed  with  fully  qualified  principal  (user)  name 
keyed  with  local  DCE  cell  group  name 
keyed  with  fully  qualified  group  name 
keyed  with  fully  qualified  cell  name 
keyed  with  fully  qualified  cell  name 
unkeyed  -  applies  to  all  entities 
unkeyed  -  applies  to  all  not  otherwise  specified 


It  should  be  clear  that,  in  environments  where  client  perfonmance  is  a  major  concern,  it  is  possible 
to  filter  out  events  that  are  attributed  to  certain  classes  of  users.  For  example,  the  audit  system 
events  associated  with  obtaining  administrator  privileges  only  could  be  examined  by  our  ID 
engine  (i.e.  throw  away  other  events  upstream  of  the  ID  engine).  This  would  reduce  the 
usefulness  of  the  tool  but  may  make  it  viable  in  certain  sites. 


Next  filters  are  applied  based  on  audit  conditions  which  can  be: 

success  the  requested  event  being  audited  was  successful 

denial  the  requested  event  being  audited  was  disallowed 

failure  the  requested  event  being  audited  was  unsuccessful 

pending  the  status  of  the  event  being  audited  was  not  yet  determined 

Finally,  the  filters  specify  what  actions  to  take  when  a  match  occurs.  Possible  actions  are: 
alarm  write  a  log  event  to  the  system  console 

log  write  a  log  event  to  the  log  file 

none  take  no  action  -  send  event  to  bit  bucket 
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all 


write  a  log  event  to  BOTH  the  system  console  and  log  file 


Along  with  the  event  class  name,  these  three  components  are  needed  to  complete  the 
specification  of  the  audit  filter.  Through  the  use  of  world_overridable  and  the  more  specific  filters, 
one  can  ensure  nothing  "slips  thorough  the  cracks"  as  time  goes  on. 


As  a  practical  example  of  how  to  use  DCE  audit  filters,  suppose  we  have  the  payroll  application 
which  has  the  following  four  code  points  where  audit  API  calls  are  made; 


#define  audit_event_query_eit5)loyee 
#deflne  aud±t^event_^add__einployee 
#deflne  audit__event_jnodify^enployee 
#deflne  audit_^event_delete^employee 


OxcOOOOOOO 

OxcOOOOOOl 

OXC0000002 

0XC0000003 


We  have  further  defined  two  event  classes  which  cover  these  discrete  events: 

enployee^query 

OxcOOOOOOO  #audit_event_query_eitiployee 

eiiployee_modify 

OxcOOOOOOl 
OXC0000002 
OXC0000003 

Suppose  also,  that  we  have  specified  (as  a  separate  activity)  that  all  employees  of  the  Payroll 
Department  are  members  of  the  "payroll"  security  group  within  the  DCE  Security  Service.  We 
can  then  specify  the  following  filters  via  the  dcecp  command  interface: 

audfilter  create  {world_overridable>  -attribute  {employee^query  success  log} 
audfilter  create  {world_overridable}  -attribute  {enployee^modify  all  all)  ' 
audfilter  create  {group  payroll}  -attribute  {enployee^query  all  none} 

create  {group  payroll)  -attribute  { enployee__inodif y  success  log} 


#  audi  t^even  t__add^eirpl  oy  ee 
#audi  t_event_inodif  y_enployee 
#audi  t^event_delete_eit5>loyee 


These  filters  combine  together  to  allow  the  Payroll  Department  employees  to  be  treated 
differently  than  all  other  employees.  Payroll  employees  may  query  records  without  any  logging, 
and  update  records  with  logging,  while  all  other  employees  with  successful  queries  have  the 
activity  logged  and  any  attempts  to  modify  are  both  logged  and  written  to  the  system  console. 

Of  course,  the  specification  and  modification  of  audit  filters  is  controlled  via  ACLs  within  the  audit 
service.  Activities  within  the  audit  service  engage  audit  service  APIs  to  complete  the  control  and 
logging  needs  of  such  a  service  -  it  uses  itself  to  record  activities  within  itself. 

3. 6. 2  Secure  Commur^ications  for  Network  Transmissions  between  IDS 
Components 

As  rnentioned  above,  DCE  Audit  Service  events  need  to  be  consolidated  across  multiple  systems 
within  the  network.  Additionally,  for  certain  intrusions,  local  agents  on  each  system  in  the  network 
could  take  actions  based  on  notification  from  some  central  authority.  Hence  the  need  for  reliable 
and  secure  communications  across  the  network. 

3.6.2. 1  DCE  Remote  Procedure  Call  (RPC) 

DCE  uses  the  Remote  Procedure  Call  (RPC)  mechanism  for  application  to  application 
communication.  The  use  of  RPC  as  a  programming  paradigm  is  well  understood  and  widely  used 
within  the  industry.  DCE  allows  RPCs  to  flow  from  one  application  to  another  with  several 
security  options  and  various  execution  semantics. 

3.6.2.1.1  RPC  Security  Options 

The  security  levels  available  to  the  application  programmer  via  the  DCE  RPC  API  are  as  follows- 
rpc_c_protectJevel_default 
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Default  protection  level  of  the  authentication  service 
rpc_c j>rotect_level_none 
No  protection. 

rpc_c j)rotect_level_connect 

Protection  provided  only  when  the  client  establishes  the  connection  with  the 
server.  An  initial  enciypted  "handshake"  indicates  the  client  and  server  are  who 
they  purport  to  be.  No  further  checking  or  encryption  is  done  after  the  initial  call. 
rpc_c j}rotect_level_call 

Protection  provided  on  each  RPC  call  to  the  server  to  ensure  the  two  parties 
have  not  changed.  This  effectively  performs  the  connect  level  of  protection  for 
each  RPC  call.  Multiple  network  packets  are  not  protected  and  no  encryption  is 
done.  (Connection-based  protocol  sequences  such  as  ncacnjpjtcp  use 
rpc_c jjrotectJevel jJkt  instead.) 
rpc_c jirotectjevel jjkt 

Protection  provided  on  each  RPC  call  and  every  message  to  ensure  the  two 
parties  have  not  changed.  This  effectively  performs  the  call  level  of  protection  for 
every  packet  sent  between  the  two  parties.  Other  than  the  encrypted 
"handshaking"  of  each  packet,  the  data  within  the  data  packets  is  not  encrypted. 
rpcjD Jirotectjevel jiktjntegrity 

Protection  provided  on  each  RPC  call  and  every  message  (like  pkt  above)  with 
the  additional  feature  that  a  cryptographic  checksum  is  computed  and  added  to 
each  message  to  ensure  the  data  within  the  packet  has  not  been  changed.  This 
is  the  highest  level  of  security  that  can  be  guaranteed  to  be  available  in  the  DCE 
runtime  base  (see  pktjarivacy  below). 
rpc_c Jirotectjevel jikt jirivacy 

Protection  provided  as  with  pktjntegrity  except  the  data  within  the  packet  is 
encrypted.  This  is  the  highest  level  of  privacy  available  -  every  message  is 
encrypted  before  it  crosses  the  wire.  Since  the  packet  data  is  normally  encrypted 
using  the  Data  Encryption  Standard  (DES),  which  has  export  restrictions  by  the 
United  States  Government,  it  may  not  be  present  in  the  runtime  that  performs  the 
encryption.  Applications  that  request  this  level  of  protection  without  support  in 
the  runtime,  will  receive  an  error.  As  with  any  cryptography,  there  are  significant 
performance  costs  associated  with  using  cryptographic  checksums  or  data 
encryption  as  in  these  highest  two  protection  levels. 

Our  Phase  I  applications  were  designed  to  implement  rpc_c jirotectjevel jikt jirivacy  as  the 
default  security  level.  This  provides  the  highest  level  of  security  but  at  a  cost  in  terms  of 
performance.  It  appears  that  RPC's  using  this  security  level  are  around  twice  as  slow  as 
unencrypted  RPC’s.  The  communications  infrastructure  appears  not  to  be  the  bottleneck  that  we 
should  be  concerned  with  however.  The  client  detection  engine  is  expected  to  consume  far 
greater  CPU  resources.  If  required,  in  Phase  II,  we  can  re-evaluate  whether  some 
communications  between  our  components  can  implement  rpc_c jirotectjevel jiktjntegrity  in 
order  to  improve  performance  slightly. 


3.6.2.1 .2  RPC  Execution  Semantics 

DCE  supports  several  execution  semantics  for  RPCs  such  that  the  sender  can  be  assured  how 
the  intended  receiver  will  receive  the  RPC  packets.  The  execution  semantics  available  to  the 
application  programmer  are  as  follows: 
at-most-once 

The  operation  must  execute  once,  partially,  or  not  at  all.  This  is  the  default  and 
most  commonly  used  form  of  execution  semantics. 
idempotent  •  maybe 

The  operation  may  execute  once,  partially,  not  at  all,  or  many  times  without 
causing  negative  behavior.  The  maybe  form  allows  the  caller  to  neither  require 
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nor  receive  any  negative  indication  even  though  the  operation  might  not  have 
executed  successfully  even  once.  No  return  parameters  are  permitted. 
idempotent  •  broadcast 

The  operation  may  execute  once,  partially,  not  at  all,  or  many  times  without 
causing  negative  behavior.  The  broadcast  form  allows  the  caller  to  send  to  one 
server  on  each  system  on  the  local  network  with  once  reply  being  received.  This 
method  does  not  require  a  client  to  connect  to  a  particular  server,  but  is  limited 
by  the  boundaries  of  broadcast  propagation  through  the  network  to  which  the 
caller  is  attached. 

As  will  be  explained  below,  there  were  components  of  our  architecture  proposed  in  the  Phase  I 
application  that  used  RPCs  using  broadcast  semantics.  Broadcast  RPC  was  attractive  as  an 
alarm  mechanism  that  might  be  both  very  secure  and  very  fast.  The  discussion  that  follows 
addresses  the  limitations  we  discovered  in  authenticated  idempotent  broadcast  RPC. 

3.6.2.1.3  Secure  Broadcast  RPC 

As  discussed  above,  secure  broadcast  RPC  was  initially  considered  an  ideal  form  of 
communication  between  our  intrusion  detection  components  in  the  case  of  an  alarm  which 
necessitated  a  widespread  response.  The  idea  was  to  combine  the 
rpc_c_protectJevel_pkt_pnvacy  security  level  with  idempotent  broadcast  semantics. 
Unfortunately,  we  discovered  that  such  a  program  cannot  be  written.  The  concept  of  a  "secret 
key"  based  security  model  (such  as  Kerberos  Version  5  upon  which  DCE  was  originally  based) 
does  NOT  fit  with  the  generalized  "network  broadcast"  semantics  initially  desired.  Each  party  in 
an  authenticated  communication  requires  a  secret  key  (distributed  by  a  Kerberos  Key  Distribution 
Center  in  this  case).  In  a  broadcast  RPC,  there  is  no  knowledge  of  all  the  potential  receivers  of 
the  broadcast  and  therefore  Kerberos  cannot  provide  secret  keys  to  the  broadcast  receivers. 
However  through  successive  efforts,  a  reasonable  alternative  solution  was  found. 

3.6.2.1.4  Secure  Broadcast  RPC  Alternative 

Our  objective  was  to  develop  a  scalable  secure  way  for  many  clients  to  receive  alert  notifications 
from  an  agent  as  well  as  possibly  forward  information  back  to  the  agent  for  propagation  and 
management  notification.  Since  the  broadcast  mechanism  was  proven  to  be  insecure,  it  was 
abandoned  as  a  useable  execution  semantic.  Instead,  the  maybe  idempotent  semantic  was 
used.  An  RPC  using  maybe  semantics  does  not  require  an  acknowledgement  from  a  receiver. 
This  leads  to  a  very  fast  RPC  from  the  sender's  point  of  view. 

In  the  context  of  our  prototypes,  a  client  at  startup,  builds  a  list  of  servers  that  should  “hear”  its 
alert  (if  an  intrusion  is  detected  locally).  Upon  detection  of  an  intrusion,  the  client  effectively 
performs  a  fast  multicast  to  all  of  the  servers  in  its  list.  A  secure  session  key  has  already  been 
obtained  by  the  client  for  conversations  with  each  of  these  servers.  The  maybe  semantics  of  the 
client  RPC  allows  it  to  RPC  alami  to  the  next  server  as  soon  as  it  has  sent  an  alami  to  the  first 
server  on  its  list.  This  means  the  client  RPC  does  not  block  waiting  on  an  acknowledgement  of 
receipt  from  any  server. 

Using  the  classical  DCE  client/server  paradigm,  we  created  an  alarm_agent  program  that 
registers  itself  in  the  DCE  Directory  Service  so  clients  can  locate  the  agent  of  choice.  This  can  be 
illustrated  as  follows: 
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Figure  3  The  Secure  Broadcast  RPC  Alternative 
The  entire  process  takes  the  following  steps; 

1)  When  started,  the  alarm_agent  server  registers  its  location  in  the  DCE  Directory 
Service  and  local  endpoint  map  as  a  server  should  to  "advertise"  its  availability. 

2)  When  started,  the  alanm_client  contacts  the  DCE  Directory  Service  to  locate  the 
server  it  should  contact. 

3)  The  DCE  Directory  Service  stores  a  series  of  Profiles,  Groups,  and  Server  Entries 
which  the  client  searches  through  to  locate  the  alarm_agent  it  should  contact.  In  the 
illustration  above,  sysA  will  contact  sysX  since  It  is  first  in  the  prioritized  Profile  entry. 

4)  The  alarm_client  registers  with  the  alann_agent  using  the  alanTi_agent's 
client_reg  ( )  interface.  This  is  a  secure  point-to-point  RPC  call,  so  botlT parties 
know  the  valid  identity  of  each  other.  It  is  a  short  lived  request  whose  only  purpose  is 
to  let  the  alarm_agent  know  that  the  alarm_client  is  out  there  and  wishes  to  be 
contacted  by  that  alarm_agent  whenever  the  alarm_agent  issues  notifications. 

5)  The  alanT1_agent  uses  the  DCE  RPC  API  rpc_binding_server  from  client  { ) 
to  convert  the  RPC  binding  handle  obtained  from  step  4  into  a  server  binding  handle. 
This  dynamically  reverses  the  client/server  relationship,  so  the  alarm_agent  can  be  a 
client  of  the  alarm_client  server.  Once  the  binding  handle  is  converted,  it  is  stored  (in 
memory)  by  the  alamfi_agent  so  it  will  know  what  clients  to  contact  when  a 
notification  is  to  be  sent. 

6)  When  a  notification  needs  to  be  sent,  the  alarm^agent  loops  through  its  list  of  known 
alarm.clients  to  retrieve  the  server  style  binding  handles  for  the  alarm_clients.  The 
alarm.agent  then  uses  a  secure  RPC  with  the  maybe  idempotent  execution 
semantic  to  send  the  notification  to  each  alarm_client  via  the  notify  o  interface 
that  the  alarm_client  supports.  Since  the  maybe  RPC  allows  no  return  parameters, 
the  alan7i_agent  proceeds  without  knowledge/concem  that  the  alarm_client  has 
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received  the  notification.  This  achieves  the  same  effect  as  the  broadcast  execution 
semantic  yet  provides  the  security  desired. 

7)  Since  the  DCE  Directory  Service  is  being  used  in  this  architecture,  greater  flexibility 
and  control  can  be  achieved.  In  the  original  design,  a  router  that  did  not  pass 
broadcast  requests  would  cause  the  audit  administrator  to  create  new  instances  of 
alann_agents  for  each  segment.  In  this  new  design,  clients/agents  can  locate  each 
other  even  across  routers  and  thus  achieve  a  greater  degree  of  reliability  in  an 
organization  where  the  audit  administrators  and  network  administrators  may  not 
always  synchronize  their  efforts.  It  can  also  have  the  effect  of  providing  a 

failover/backup  mechanism  in  the  event  of  a  primary  alami_agent  being  down  or 

unavailable  for  some  reason. 

The  prototype  was  developed  and  proven  using  the  above  methods  with  good  success.  We 
believe  this  is  a  better  long  term  solution  than  the  "secure  broadcast  RPC"  mechanism  proposed 
originally.  [See  Appendix  A  for  related  source  code] 

3.6.3  Detecting  Intrusions  using  Centralized  Security  Services 

Paramount  to  our  design  is  the  desire  to  limit  the  CPU  bandwidth  used  by  our  client  Intrusion 

Detection  component.  To  that  end,  the  more  intrusion  data  we  can  direct  to  our  centralized 

detection  component,  the  lower  the  load  will  be  on  the  clients.  It  became  apparent  in  our  Phase  I 
proof  of  concept  work  that  there  would  likely  be  few  applications  making  direct  calls  for 
authentication  to  a  centralized  security  component  unless  that  component  is  integrated  into  the 
base  operating  system  from  the  ground  up.  With  both  the  DCE  security  server  and  the  NT  5.0 
domain  controller  (as  advertised)  options  exist  to  integrate  what  would  othenwise  be  local 
authentication  and  authorization  requests  into  a  centralized  server.  Much  effort  was  expended, 
therefore,  on  ensuring  that: 

1)  We  can  integrate  UNIX  and  NT  security  into  a  central  domain,  and 

2)  The  effect  of  this  integration  is  that  local  authorization/authentication  requests  are 
auditable  centrally. 

3.6.3. 1  Integrated  Login  and  Single  Sign-On 

The  vendors  providing  DCE  to  the  market  place  have  responded  to  customer  demands  for  single 
sign-on  capabilities  by  leveraging  the  DCE  identity  credentials  across  the  environment.  These 
credentials  are  used  by  the  various  "security  aware"  programs  to  allow  access  in  place  of 
prompting  for  a  userid/password.  The  credentials  are  specially  encrypted  such  that  neither  the 
sender  nor  recipient  can  decrypt  the  information,  but  only  the  DCE  Privilege  Service  can  encrypt 
and  decrypt  it.  This  ensures  that  the  "trusted  third  party"  protocol  is  maintained  across  the 
environment.  Whenever  an  authentication  function  is  required,  the  encrypted  Extended  Privilege 
Attribute  Certificate  (user  credential)  is  presented  in  lieu  of  a  userid/password.  Thus  no 
passwords  are  sent  across  the  network,  thereby  strengthening  the  enterprise's  security  posture. 


The  tenn  "integrated  login"  often  refers  to  an  implementation  where  two  security  paradigms  are 
used  at  the  same  time  (local  operating  system  security  and  DCE  security),  but  the  authentication 
process  has  been  combined  into  one  event.  When  the  user  conducts  a  login,  the  same  userid 
and  password  are  used  to  authenticate  to  both  security  paradigms  at  once.  This  integrated 
approach  has  the  desirable  event  of  a  single  user  action,  and  yet  allows  legacy  security  methods 
to  be  supported  without  significant  change. 

The  term  "single  sign-on"  often  refers  to  an  implementation  where  there  are  may  be  two  security 
paradigms  but  the  DCE  security  provides  the  actual  authentication  process  on  behalf  of  both 
paradigms.  This  has  the  significant  advantage  that  the  administrative  burden  of  maintaining  two 
security  paradigms  (and  synchronizing  the  multiple  databases)  is  reduced  to  half. 


When  DCE  was  first  designed  by  the  OSF,  the  single  sign-on  paradigm  was  the  intended  design 
goal.  However,  the  implementation  was  left  to  the  vendor's  discretion.  Though  this  area  has 


Page  24 


Printed  01/19/98 


been  languishing  for  some  time,  it  has  gained  renewed  emphasis  and  development  effort  from 
several  vendors  -  IBM  most  notably.  Without  these  implementations,  the  user  must  first 
authenticate  to  the  local  operating  system,  then  perform  a  separate  dcejogin  to  authenticate  to 
the  DCE  security.  This  method  can  have  advantages  when  a  significant  portion  of  the  users  will 
not  be  using  DCE. 

DCE  is  often  employed  to  provide  enhanced  security  and  file  services  throughout  an  enterprise, 
thus  single  sign-on  is  of  great  interest  to  serious  enterprises.  IBM  suggests  an  annual  savings  for 
an  enterprise  of  about  10,000  users  to  be  over  $8,000,000  dollars  in  end-user  productivity  gains  - 
administrative  and  security  enhancement  savings  would  be  additive  to  that  number.  [9] 

3.6.3.2  Integrated  Login  under  Microsoft's  Windows  95  and  Windows  NT 

The  Microsoft  platfonns  have  been  supported  by  several  vendors  who  provide  the  DCE  product. 
Most  notable  in  the  field  is  Gradient  Technologies  [10]  who  has  focused  on  Windows  from  the 
outset.  They  offer  a  wide  range  of  DCE  based  products.  In  their  implementation,  when  the  DCE 
software  is  installed,  you  are  provided  the  option  to  use  "integrated  login”.  This  allows  the  user  to 
have  a  userid  in  both  the  Windows  and  DCE  security  databases,  with  changing  of  passwords 
being  done  in  both  places  at  once.  The  user  integrated  login  is  limited  to  the  local  system, 
meaning  that  while  Windows  security  token  are  passed  from  system  to  system,  the  DCE 
credentials  are  not,  thus  forcing  a  DCE  re-authentication  at  each  system  boundary.  With  the  use 
of  DCE/DFS  and  truly  distributed  services,  the  user  need  not  cross  the  system  boundary  so  the 
impact  is  limited. 

International  Business  Machines  (IBM)  and  Digital  Equipment  Corporation  (DEC)  have  provided 
Windows  based  DCE  products  for  some  time  as  well.  IBM's  version  is  a  serious  competitor  to  the 
Gradient  product  and  likewise  has  an  enabled  integrated  login  fadlity.  [11] 

Since  NT  5.0  Domain  Controllers  (running  under  Active  Directory)  were  not  released  at  the  time 
the  Phase  I  work  was  performed,  it  was  impossible  to  test  the  equivalent  integrated  network  login 
through  the  Microsoft-centric  solution.  We  expect  to  confirm  Microsoft's  claims  of  seamless 
integration  of  NT  security  into  a  Kerberos  V  based  environment  as  soon  as  NT  5.0  becomes 
commercially  available. 

3.6.3.3  Single  Sign  On  under  IBM's  AIX 

IBM  has  made  great  commitment  to  DCE  development  and  has  thus  changed  their  AIX  operating 
system  to  embrace  the  DCE  security  paradigm.  [11]  This  means  that  the  Systems  Administrator 
adds  users  to  the  DCE  Registry  and  has  no  need  to  add  the  user  to  local  operating  system  files. 
An  extra  process  on  the  local  operating  platfonn  performs  the  gateway  operation  between  local 
authentication  and  DCE  authentication. 

Of  all  vendors,  IBM  appears  most  committed  to  developing  the  most  sophisticated  single  sign  on 
product  base.  On  January  13*^,  1998,  IBM  announced  a  significant  enhancement  and  extension 
to  their  Global  Sign-On  (GSO)  product  line,  which  takes  the  single  sign-on  to  new  heights.  [12] 

3.6.3.4  Integrated  Login  under  HP's  HP-UX 

Hewlett-Packard  (HP)  [13]  has  also  made  great  commitment  to  DCE  development  and  has 
likewise  changed  their  HP-UX  operating  system  utilities  to  embrace  the  DCE  security  paradigm 
while  allowing  a  fallback  to  the  traditional  HP-UX  paradigm  if  DCE  security  is  unavailable.  While 
not  as  robust  as  IBM's  approach,  it  is  a  significant  capability  which  aids  in  supporting  a 
centralized  security  model,  and  is  manageable  for  an  enterprise  to  implement. 

3.6.3.5  Integrated  Login  under  SunSoft's  Solaris  using  Transarc's  DCE 

Hindered  in  that  they  do  not  own/control  the  operating  system.  Transarc  [14]  has  been  slow  to 
implement  integrated  DCE  solutions  with  Solaris.  SunSoft  has  not  chosen  to  really  embrace  the 
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DCE  technology  leaving  Transarc  as  the  primary  DCE  vendor  in  for  this  operating  platform. 
Transarc  is  the  DCE/DFS  technology  provider  on  almost  all  platforms. 

3.6.3.6  Remote  Access  Security  using  SnareWorks 

Provided  by  IntelliSofl,  SnareWorks  [15]  is  a  product  that  can  insert  DCE  security  into  an 
othennrise  uncooperative  environment.  SnareWorks  is  able  to  insert  itself  in  the  socket  layer  and 
intercept  packets  as  they  flow  from  remote  systems  to  applications  on  the  local  system. 
Employing  "Protocol  Support  Modules"  and  predefined  entry  points,  SnareWorks  can  enforce 
security  rules  with  DCE  ACLs.  Using  this  technology  on  the  sender  and  receiver  side,  credentials 
can  be  provided  for  authentication.  This  effectively  provides  a  full  single  sign-on  solution  not  only 
for  the  traditional  system  utilities  (login,  telnet,  ftp,  etc.),  but  any  socket  based  inter-process 
communication  desired  by  an  enterprise.  While  not  as  easy  to  implement  for  an  enterprise,  it  is 
the  most  flexible  and  extensible  of  all. 

3.6.4  Response  Techniques 

Our  prototype  response  tools  have  three  key  elements  for  response  to  intrusion: 

1)  Access  to  centralized  security  registry, 

2)  Authentication  credentials  (from  our  use  of  authenticated  RPC), 

3)  Access  Control  Lists  (ACLs). 

The  DCE  Security  infrastructure,  around  which  our  Phase  II  production  response  tools  are  based, 
is  based  to  two  contributing  technologies:  1)  MIT  Project  Athena's  Kerberos  Network 
Authentication  Service,  Version  5  and  2)  HP/Apollo’s  centralized  passwoixl  registry  (database). 


3.6.4. 1  The  Security  Model  applied  to  Response  Capability 

The  DCE  Registry  is  the  centralized  and  replicated  security  database.  It  contains  information 
about  all  the  security  entities,  called  principals,  in  the  DCE  cell  (a  logical  collection  of  systems). 
The  association  of  a  principal  with  a  password,  a  primary  group,  organization  and  other 
information  comprises  an  account.  A  user/server  must  have  an  account  in  order  to  authenticate 
to  the  DCE  Security  Service. 

An  important  guard  against  intrusion  is  to  ensure  the  strength  of  passwords.  DCE  allows  the 
definition  of  the  following  password  policies  in  the  normal  Registry  schema: 

■  lifespan 

■  expiration  date 

■  minimum  length 

■  consist  of  ali  spaces 

■  consist  of  all  alphanumeric  characters 

DCE  1.1  provides  an  integrated  password  strength  subsystem,  which  may  be  used  to  extend  the 
management  of  password  strength  and  password  generation.  DCE  provides  an  example 
password  strength  server  which  may  be  customized.  This  password  strength  subsystem  relies 
on  the  use  of  ERAS  in  the  Registry  to  require  a  principal’s  password  be  validated  by  the 
subsystem.  One  of  the  response  techniques  listed  below  relies  on  the  ability  to  customize 
password  strength  checking  to  prevent  use  of  passwords  that  have  been  compromised. 

Access  Control  Lists  (ACLs)  are  used  to  control  access  to  objects  (resources)  in  DCE.  These 
POSIX  1003.6/Drafl  3  based  ACLs  contain  a  list  of  users  and  groups  that  are  allowed  access  to  a 
resource  and  what  type  of  access  is  allowed.  Applications  may  grant  access  to  resources  with  a 
high  degree  of  granularity  (e.g.  unauthenticated  users,  specific  users  from  a  foreign  cell).  The 
use  of  ACLs  requires  the  application  responsible  for  the  resource  to  provide  one  or  more  ACL 
Manager  routines.  These  routines  are  used  to  compare  the  authorization  information  sent  from 
the  client  against  the  ACL  entries  from  the  ACL  database  residing  within  the  application.  Access 
is  granted  or  denied  based  on  the  outcome  of  the  comparison. 
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Authentication  credentials  are  obtained  when  a  user  authenticates  with  the  DCE  Security  Service 
(i.e.  logs  into  the  DCE  cell).  They  expire  after  a  specific  period  of  time.  Credentials  are  used  to 
prove  the  user's  identity  in  the  cell  without  having  to  provide  a  password  again.  The  length  of 
time  that  credentials  are  valid  is  determined  by  authentication  policy  within  the  Registry. 
Credentials  contain  of  three  types  of  information:  TGT,  PAC,  and  service  tickets.  The  Ticket 
Granting  Ticket  (TGT)  is  used  to  prove  the  identity  of  the  user  and  can  only  be  decrypted  by  the 
Security  Service.  The  Priviiege  Attribute  Certificate  (PAC)  contains  the  project  list,  simply  a  list  of 
authorization  groups  in  the  Registry  to  which  the  principal  belongs.  In  DCE  1.1,  the  PAC  was 
enhanced  and  is  now  property  referred  to  as  the  Erdended  Privilege  Attribute  Certificate  (EPAC). 
A  service  ticket  is  obtained  by  the  client  in  order  to  request  service  from  a  server.  The  service 
ticket  proves  to  the  application  server  the  client's  identity.  The  ACL  manager  compares  the  PAC 
to  the  ACL  protecting  the  resource  to  determine  whether  the  client  is  authorized  to  perform  the 
operation  requested. 

Non-human  users,  servers,  use  keytab  (key  table)  files  to  store  their  account  passwords.  A 
keytab  contains  one  or  more  principal/password  pairs.  It  is  normal  file,  which  is  read  by  an 
application  when  authenticating  to  DCE.  Thus  all  principals  "login"  to  DCE. 

The  below  diagram  illustrates  the  interaction  between  the  various  parts  of  DCE  security. 


3.6.4.2  Using  DCE  Security  Services  as  a  Response  Technique 

Based  upon  our  Phase  I  proof  of  concept  work  we  are  confident  that,  once  an  intrusion  has  been 
detected,  one  or  more  of  the  following  actions  may  be  used  to  respond  to  the  threat. 

3.6.4.2.1  Prevent  ticket  renewal 
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We  are  able  to  set  the  maxtktrenew  attribute  on  the  compromised  account  to  zero  to  prevent 
existing  credentials  from  being  renewed.  The  renewable  ticket  lifetime  determines  the  maximum 
length  of  time  tickets  may  be  refreshed  before  new  login  is  required. 

3.6.4.2.2  Invalidate  existing  credentials 

Our  response  prototype  is  able  to  set  the  goodsince  attribute  on  the  account  to  the  current 
date/time  and  generate  a  new  password  for  the  account.  Any  tickets  granted  before  the  date  and 
time  indicated  in  the  goodsince  attribute  will  not  be  valid.  To  obtain  new  credentials,  the  new 
uncompromised  (hopefully)  password  must  be  used. 

3.6.4.2.3  Remove  access  to  threatened  object 

If  pennission  is  granted  to  the  singular  principal  whose  account  has  been  compromised,  then  we 
may  change  the  ACL  protecting  the  object  to  give  no  permission  to  the  compromised  principal.  In 
the  case  that  the  compromised  account  gains  access  from  being  a  member  of  an  authorization 
group  having  permissions  to  the  object,  then  either  add  a  more  restrictive  ACL  entry  reducing  the 
privileges  for  that  principal  or  remove  the  principal  from  that  security  group. 

3.6.4.2.4  Disable  compromised  account 

We  rriay  set  the  acctvalid  attribute  to  no.  This  will  prevent  any  future  login  to  the  account.  Notify 
security  administrators  who  will  decide  the  next  action,  perhaps  removal  of  the  account.  This 

response  will  likely  be  used  with  other  responses  depending  on  the  risk  assessment  of  the 
intrusion. 


3.6.4.2.5  Disable  administrative  accounts  (cell_admin  and  all  accounts  belonging 
to  administrative  groups) 

Our  prototypes  are  able  to  set  the  acctvalid  flag  on  the  cell.admin  account  to  no,  preventing 
future  logins  as  that  privileged  user.  We  can  also  set  the  inprojlist  attribute  on  the  administrative 
accounts  to  no,  preventing  it  from  inclusion  in  any  future  Privilege  Attribute  Certificates  (PAC) 
issued  by  the  Security  Service 


3.6.4.2.6  Regenerate  login  key  for  authenticated  application 

Generate  a  new  password  for  the  application.  It  will  be  stored  in  both  the  keytab  and  the 
Registry  Remove  the  previous  password  in  the  keytab.  Re-start  the  application  to  use  the  new 
password.  This  may  be  handled  securely  from  any  system  participating  in  the  cell  and  thus  does 
not  require  logging  into  the  actual  system  where  the  application  runs. 


3.6.4.2.7  Regenerate  login  keys  for  machine  principal 

Gen^ate  a  new  password  for  the  system  (machine).  It  will  be  stored  in  both  the  keytab  and  the 
Regi^ry.  Reinove  the  previous  password  in  the  keytab.  Re-start  the  security  client  process 
(deed)  to  use  the  new  password.  This  must  be  done  from  the  console  of  the  machine  to  ensure 
the  password  is  securely  changed. 


3.6.4.2.8  Shutdown  breached  application 

The  application  may  be  shutdown  from  any  machine  that  participates  in  the  cell  by  using  the  DCE 
application  management  facilities  included  in  DCE  1.1  core  services.  This  presumes  the 
application  has  already  been  configured  to  be  managed  through  DCE  -  a  one-time  configuration 
task  performed  by  a  systems  administrator.  ^ 


3.6.4.2.9  Reinitialize  authenticated  application 

The  application  may  be  re-started  from  any  machine  that  partidpates  in  the  cell  by  using  DCE 
application  management  facilities.  This  presumes  the  application  has  already  been  configured  to 
be  managed  through  DCE. 
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3.6.4.2.10 Restore  original  application  binary 

If  the  application  binary  is  stored  in  DCE's  DFS  (Distributed  File  Service)  in  an  unmounted  read- 
write  fileset,  it  could  easily  be  mounted  and  copied  over  the  compromised  binary  with  the  original 
ACLs  intact. 

3.6.4.2.11  Notify  password  strength  subsystem  (compromised  password  now 
considered  weak) 

If  a  password  is  compromised,  perhaps  by  an  enhanced  dictionary  attack,  notify  the  password 
strength  subsystem  to  prevent  users  from  choosing  that  password  in  the  future. 

3.6.4.2.12Re-encrypt  security  database  with  newly  generated  key 

Force  generation  of  a  new  master  key  and  re-encryption  of  the  entire  security  database.  This 
copy  of  the  database  would  be  unavailable  during  the  re-encryption  task. 

3.6.4.3  Choosing  an  Appropriate  Response  Technique 

A  risk  assessment  would  be  performed  to  detemnine  which  actions  from  the  list  above  is  the  most 
appropriate  response  to  the  intrusion.  DCE's  extended  registry  attributes  (ERAs)  could  be  used 
to  store  the  potential  threat  level  on  a  per  account  basis.  In  this  way,  when  an  account  is 
compromised  the  risk  associated  with  the  use  of  the  account  could  be  automatically  be  assessed 
and  the  appropriate  response  taken  without  human  intervention.  Below  is  one  possible 
assignment  of  risk  to  level.  Further,  ERAs  could  be  used  to  maintain  a  list  of  appropriate 
responses  on  an  account  by  account  basis,  based  on  a  specific  threat  level. 

0  standard  access  user  account 

1  standard  access  server  application  account 

2  confidential  access  user  account 

3  confidential  access  server  application  account 

4  administrative  access  account 

3. 6. 5  Events  Detected  by  our  Central  Audit  Monitor 

Crucial  to  our  entire  architecture  is  the  need  to  detect  some  proportion  of  intrusions  through  our 
central  Audit  Monitor  (attached  to  the  audit  trail  of  the  DCE  security  service).  Using  the  audit 
events  provided  by  the  core  DCE  servers  combined  with  the  vendor  integrated  login  components, 
intrusion  scenarios  were  developed. 

3.6.5. 1  Security  Anomalies  that  can  be  detected  by  the  proposed  Audit  Monitor. 

The  Audit  Monitor  interfaces  with  the  DCE  Audit  Service.  The  DCE  Audit  Service  is  able  to  audit 
all  of  the  DCE  servers  that  physically  reside  on  that  physical  computer.  One  of  the  most 
significant  server  processes  that  is  audited  by  the  Audit  Server  is  the  DCE  Security  Server.  The 
events  that  the  Audit  Monitor  can  locate  via  the  DCE  Audit  Server  are  as  follows: 

Attempts  to  modify  (or  delete)  parts  of  the  DCE  security  database  (the  registry) 

This  can  include  just  about  any  change  to  user  account 
infomiation,  group  information  ora  change  in  a  policy  of 
the  security  service  itself. 

Changes  to  Access  Control  Lists  (ACLs)  can  also  be  detected 
in  this  manner. 

Attempts  to  initialize  or  delete  a  DCE  security  server 

It  is  important  to  avoid  the  possibility  of  an  attack  that  is 
aimed  purely  at  "denial  of  service".  An  attempt  to  shut  down 
one  or  more  copies  of  the  security  server  would  fit  this 
category. 
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Any  login  to  the  DCE  security  server  computer 

Much  of  DCE  security  relies  on  the  fact  that  the  systems  that 
hold  the  security  database  (the  registry)  are  physically  and 
logically  secure.  The  only  time  a  login  request  should  be 
entered  to  a  security  server  is  during  system  maintenance.  If 
a  login  attempt  is  detected  at  any  other  time,  there  is  the 
potential  that  someone  is  attempting  to  break  in. 

Attempts  to  regenerate  the  key  used  to  encrypt  the  security  database 
The  whole  of  the  DCE  security  database  is  encrypted  on  disk.  A 
master  encryption  key  is  used  to  encrypt.  An  attacker  may 
attempt,  through  whatever  means,  to  somehow  re-encrypt  the 
database  with  a  known  key. 

Failed  client  responses  to  a  server’s  challenge 

DCE  version  1.1  includes  a  login  protocol  that  is  much  more 
secure  than  the  kerberos  protocol  from  which  it  was  derived. 

In  this  newer  DCE  version,  an  improved  mutual  authentication 
check  is  initiated  between  client  and  server  i.e.  both  clients 
and  servers  must  prove  who  they  are.  If  a  client  or  server 
fails  this  mutual  challenge  this  is  a  possible  sign  of  attack. 

Detected  replays  of  previous  security  operations 

DCE  security  relies  on  ticket  transfers  across  a  network. 

An  attacker  might  attempt  to  break  down  security  by  re-playing 
an  old  ticket  request. 

Invalid  ticket  requests 

Any  ticket  request  that  is  either  an  invalid  type  or  a 
prohibited  type  should  raise  an  alarm. 

The  usage  of  cryptographic  keys  in  the  DCE  RPC  runtime 

It  is  possible  to  detect  any  time  that  any  client  tries  to  use 
some  form  of  DCE-based  encryption. 

Attempts  to  change  the  system  time  (to  re-use  expired  tickets) 

In  order  to  attempt  to  replay  an  old  (expired)  ticket,  the 
system  time  of  a  server  would  have  to  be  set  backwards. 

This  condition  should  always  raise  an  alarm. 

Attempts  to  turn  off  or  modify  the  DCE  Audit  Service 
These  events  should  clearly  be  audited  ! 

Attempts  to  connect  to  the  security  server  through  any  means  other  than  authenticated  DCE  RPC 
The  DCE  security  server  should  only  be  accessed  by 
authenticated  DCE  RPC.  Any  other  form  of  attempted  access 
e.g.  ftp,  telnet,  mail,  etc  is  a  likely  sign  of  attack. 

The  correlation  of  these  esoteric  events  to  known  intrusions  is  the  heart  of  our  detection 
philosophy.  This  correlation  makes  up  the  rules  of  our  rule  based  detection  tools.  A  brief  six 
month  proof  of  concept  effort  does  not  provide  the  time  to  tie  large  numbers  of  well-known 
intrusions  to  specific  patterns  of  events  above,  however,  based  on  our  research,  we  are  confident 
that  some  proportion  of  intrusions  can  be  detected  in  this  manner.  The  remaining  well-known 
intrusions  shall  be  detected  by  rules  applied  at  the  local  client  monitors. 
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3.6.5.2  Responses 

Based  on  our  research,  in  response  to  an  alert,  the  following  actions  can  be  implemented  across 

the  entire  DCE  cell: 

Regeneration  of  the  machine  key  for  each  affected  system. 

DCE  uses  a  machine  key  (like  a  password)  as  proof  of  a  client 
computer's  identity.  This  key  is  also  used  as  the  basis  for 
the  encryption  keys  that  are  used  to  transmit  information  from 
a  client  to  the  security  server).  After  a  suspected  security 
breach,  regeneration  of  this  key  will  ensure  that  an  attacker 
can  no  longer  use  a  key  he  or  she  has  obtained. 

Modification  to  the  behavior  of  the  DCE  password  strength  subsystem 
DCE  implements  a  password  strength  server  to  control  the 
quality  of  user  passwords  in  a  security-sensitive 
environment.  It  is  possible  to  raise  the  limitations  on  the 
passwords  that  users  are  allowed  to  create  and  therefore  impose 
stricter  password  strength  policies. 

Disabling  accounts  for  which  there  have  been  attacks 

This  is  one  of  the  most  common  actions  currently  taken  as  a 
result  of  a  security  alert.  In  a  DCE-based  environment,  with 
its  centralized  security  service,  it  is  possible  to  disable  a 
particular  account  across  thousands  of  systems  instantly. 

Re-encryption  of  the  DCE  security  database  with  a  newly  generated  key 
This  action  can  even  be  initiated  without  shutting  down 
security  entirely. 

Imposition  of  stricter  auditing  requirements  across  all  DCE  applications 
Obviously  this  is  an  after-the-fact  improvement,  but  K  may  be 
very  valuable  nevertheless 

Re-generation  of  the  login  keys  used  by  authenticated  application  servers 
DCE  application  servers  store  their  login  keys  (passwords)  in 
files  on  disk.  After  a  security  breach,  there  is  the  potential 
that  these  files  could  have  been  read  by  an  intruder  &  the 
keys  could  have  been  learned.  It  therefore  makes  sense  to  re¬ 
generate  these  keys  after  a  suspected  breach. 

Shorten  the  life  span  of  existing  and  future  DCE  tickets 

After  a  successful  attack,  an  intruder  will  have  obtained  one 
or  more  tickets  from  the  DCE  security  server.  In  order  to 
prevent  the  attacker  from  doing  further  damage,  the  lifespan 
of  his  or  her  tickets  may  be  set  to  zero. 

Raise  an  appropriate  alarm  to  inform  security  administration  staff 
Regai^less  of  the  degree  of  automation  of  this  proposed  tool, 
it  is  important  to  inform  security  operations  of  a  breach  so 
that  other  measures  may  be  taken  against  the  attacker. 

Temporarily  disable  each  DCE  administrator  account 

It  may  make  sense  to  disable  all  administrative  accounts  so 
that  no  privileged  operations  can  be  performed  until 
maintenance  is  completed  by  a  person  with  physical  access  to 
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the  console  of  the  security  server  host. 

Shut  Down  All  Applications 

In  some  environments  denial  of  service  is  preferred  to 
unauthorized  data  access.  In  these  environments,  shutdown  of 
applications  is  possible  via  the  Distributed  Agent  running  on 
each  system. 

3.7  Overall  System  Architecture 

The  end  result  of  the  research  effort  was  to  start  with  an  architectural  concept,  develop  and 
modify  it  until  a  valid  architecture  was  prototyped  from  which  a  commercial  grade  product  could 
be  built. 

The  key  elements  of  the  original  proposal  were; 

1)  an  Administrative  Client, 

2)  a  set  of  Centralized  Audit  Monitors, 

3)  a  (much  larger)  set  of  Distributed  Agents,  and 

4)  a  (one-per-network-segment)  set  of  Alert  Agents. 

These  components  are  documented  in  the  pages  that  follow. 

The  previous  pages  in  this  report  document  a  phase  II  prototype  that  differs  from  the  original 
Phase  I  proposal  in  two  main  ways: 

1)  The  use  of  a  multicast  RPC  using  “maybe”  semantics  was  required  as  a  replacement  for 
broadcast  RPC,  and 

2)  The  original  Phase  I  application  architecture  was  based  on  the  naive  assumption  that  all 
intrusions  would  manifest  themselves  in  auditable  events  at  a  centralized  security  server. 
The  modified  architecture  we  have  explained  in  this  report  calls  for  a  lightweight  client 
Intrusion  Detection  component  at  each  client  system. 

While  these  differences  are  significant,  they  did  not  drastically  alter  the  overall  architecture.  This 
reinforced  our  confidence  in  our  initial  design  and  assumptions.  Integration  with  pre-existing  IDS 
technologies  is  expected  to  alter  the  design  to  some  degree,  but  the  overall  architecture  appears 
to  be  sound  based  on  our  research  and  integration  efforts  thus  far.  The  pages  that  follow 
document  the  originally  proposed  architecture. 
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Figure  5  System  Architecture  -  Operation  of  the  Distributed  Agent 

The  figure  above  shows  the  operation  of  a  Distributed  Agent.  The  primary  role  of  the  Distributed 
Agent  is  to  implement  any  local  security  policy  decisions  based  on  information  provided  by  an 
Administrative  Client  or  an  alert  from  an  alert  agent.  A  secondary  role  is  to  raise  an  alert  based 
on  local  monitoring  of  IP  ports.  The  Distributed  Agent  is  a  privileged  process  and  is  able  to  stop 
and  start  processes  that  may  be  at  risk  in  the  event  of  an  attack. 
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Figure  6:  The  Audit  Monitor 


Figure  6  System  Architecture  -  The  Audit  Monitor 

The  above  figure  shows  the  operation  of  an  Audit  Monitor.  The  DCE  Audit  Service  is  able  to 
monitor  security-related  events  across  very  large  heterogeneous  networks.  The  instance  of  the 
DCE  audit  server  attached  to  the  DCE  security  server  host  is  especially  significant.  This  DCE 
security  server  will  receive  authentication  requests,  ticket  requests  and  requests  to  change 
security  policies  etc  from  DCE  and  non-DCE  applications  across  the  entire  DCE  cell.  The  DCE 
audit  server  attached  to  the  security  server  can  be  configured  to  log  all  security  related  events  in 
a  cell  (all  the  way  down  to  every  POSIX  getuidQ  call  in  the  entire  distributed  cell).  The  proposed 
Audit  Monitor  would  therefore  be  able  to  identify  events  of  concern  via  a  secure  interface  with  the 
DCE  Audit  Service  and  raise  alarms  as  required  to  the  Alert  Agent  in  the  local  network  segment. 
These  alarms  could  take  the  form  of  secure  (encrypted)  multicast  DCE  Remote  Procedure  Calls 
(RPCs). 
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Figure  7  System  Architecture  -  The  Administrative  Client 

The  figure  above  shows  the  operation  of  an  Administrative  Client.  The  administrative  client  has 
the  facility  to  define  what  events  should  raise  an  alarm.  The  Administrative  Client  defines  the 
events  that  should  raise  an  alarm  and  the  actions  expected  as  a  result  of  each  alarm.  This 
information  needs  to  be  disseminated  to  every  Distributed  Agent  (of  which  there  could  be  many 
thousands)  and  to  each  Audit  Monitor  (there  may  be  two  for  a  replicated  DCE  security  database). 
It  is  impractical  for  the  Administrative  Client  to  access  each  Distributed  Agent  directly,  therefore  a 
two-tiered  architecture  is  employed.  An  Alert  Agent  resides  in  each  network  segment  and  can  be 
located  via  the  DCE  directory  service  (CDS).  The  Audit  Monitors  can  be  located  in  a  similar 
manner.  The  Administrative  Client  locates  each  Alert  Agent  and  Audit  Monitor  &  sends  policy 
updates  via  secure  (encrypted)  DCE  RPC  (non-broadcast).  The  Alert  Agents  located  in  each 
ne^ork  segment  then  issue  a  secure  (encrypted)  broadcast  RPC  to  each  of  the  clients 
(Distributed  Agents)  in  their  network  segment. 
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Figures:  The  Alert  Agent 


Figure  8  System  Architecture  -  The  Alert  Agent 

The  figure  above  shows  the  operation  of  an  Alert  Agent.  At  process  startup,  each  Alert  Agent 
register  its  location  in  the  DCE  directory  service  (CDS).  Each  Alert  Agent  can  "hear  alarms 
from  Distributed  Agents  or  Audit  Monitors  in  the  local  network  segment  (since  these  alarms  would 
be  based  on  secure  broadcast  RPC).  Systems  in  a  network  segment  will  not  respond  to  the  alert 
initiated  by  Distributed  Agent  as  shown  in  Figure  8  middle  left,  but  instead  will  wait  to  hear  an 
alert  from  the  Alert  Agent.  The  advantage  here  is  that  the  Alert  Agent  will  run  on  an  operating 
system  with  a  greater  level  of  security  than  most  desktop  systems.  It  is  therefore  possible  for  the 
Alert  Agent  to  perform  a  mutual  authentication  check  to  the  Distributed  Agent  raising  the  alarm  in 
order  to  verify  the  true  identity  of  the  system  raising  the  alann  and  avoiding  nuisance  alerts  from 
external  sources. 

In  order  to  securely  implement  the  suggested  architecture,  each  system  in  the  infrastructure  must 
be  configured  into  a  DCE  cell.  At  first  it  might  therefore  appear  that  only  DCE  applications  could 
benefit  from  this  intrusion  detection  system.  This  is  by  no  means  the  case,  in  fact,  as  long  as 
each  system  is  configured  with  "Integrated  DCE  Login",  every  security  interaction  that  previously 
was  channeled  to  the  local  operating  system  is  now  passed  to  the  DCE  security  server.  In  this 
fashion,  systems  (including  non-DCE  applications)  can  be  monitored  and  served  by  a  DCE-based 
intrusion  detection  and  response  tool  with  a  low  overhead. 
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Figure  9  System  Architecture  -  DCE  Integrated  Login 

The  figure  above  illustrates  the  use  of  Integrated  DCE  Login  to  allow  non-DCE  applications  to 
make  use  of  DCE  audit.  DCE  integrated  login  replaces  the  operating  system  library  that  holds 
POSIX  security  calls  such  as  getuidQ  and  routes  those  calls  to  a  centralized  security  server.  A 
DCE  audit  server  at  this  location  will  therefore  be  able  to  log  events  from  non-DCE  processes 
throughout  the  DCE  cell.  The  use  of  secure  (encrypted)  Remote  Procedure  Calls  (RPCs) 
throughout  the  design  facilitates  secure  communications.  The  centralized  nature  of  the  resultant 
security  system  implies  that,  when  an  attack  is  identified,  modifications  to  security  policies  are 
required  ONLY  at  the  DCE  security  server  and  these  modifications  are  seen  instantly  by  clients 
(hence  speeding  up  the  response  to  an  attack). 
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4  Results  and  Discussion 


Over  the  last  seven  months,  much  pure  research  has  been  conducted.  Much  more,  in  fact,  than 
was  promised  in  our  Phase  I  application.  We  have  conducted  extensive  literary  searches, 
reading  and  studying  papers  that  cover  the  last  two  decades.  We  have  identified  the  position  in 
the  market  place  where  our  commercial  grade  Intrusion  Detection  System  (IDS)  would  fit.  We 
have  identified  potential  customers  of  such  a  system. 

We  have  made  contacts  with  key  players  in  the  field  who  have  been  engaged  in  this  work  for 
many  years.  We  have  attended  conferences  to  further  develop  these  contacts.  Through  these 
contacts,  we  have  obtained  source  code  for  three  existing  systems.  We  studied  these  systems 
and  have  had  success  in  integrating  DCE  Audit  Services  events  with  two  of  these  systems. 

We  have  developed  a  viable  secure  multicast  RPC  method  that  is  scalable,  efficient  and  can  be 
made  to  be  fault  tolerant.  We  have  developed  an  interface  to  the  DCE  Audit  Service  that  uses 
the  standard  Audit  Service  APIs  in  an  effective  way  for  use  by  a  real-tirrie  IDS.  We  have 
discovered  that  there  are  serious  bugs  in  some  vendor  DCE  Security  Service  implementations 
and  are  working  with  the  vendor  community  to  resolve  this  deficiencies. 

From  a  response  perspective,  we  have  proven  we  can  invalidate  access  and  reduce  access  on  a 
global  and  discrete  level.  We  have  shown  that  DCE  Single  Sign-on  will,  in  fact,  generate  Security 
Service  audit  events  that  can  be  seen  by  an  IDS. 

We  know  we  have  the  enthusiastic  endorsement  of  outside  sponsors  who  wish  us  to  pursue  full 
scale  development  of  a  commercial  grade  IDS  and  have  offered  their  financial  support  for  us  to 
do  so.  We  know  that  we  will  be  able  develop  an  audit  data  collection  mechanisrn  that  will  be 
efficient,  secure  and  fault  tolerant  across  many  systems.  This  will  enable  a  true  "single  system 
image”  view  desperately  needed  by  a  commercial  grade  IDS. 

We  can  build  a  hierarchical  notification  alert  mechanism  that  will  be  scalable,  secure,  and  fault 
tolerant.  This  notification  mechanism  will  aid  in  the  overall  effectiveness  and  management  of  a 
highly  distributed  IDS. 

We  believe  that  the  DCE  based  Single  Sign-on  products  available  today  are  not  all  inclusive  and 
will  need  to  be  augmented.  We  know  that  a  "lightweight  client  monitor"  will  be  required  to  search 
for  intrusions  invisible  to  our  centralized  IDS.  We  also  know  that  there  are  DCE  based  products 
currently  available  (separate  and  distinct  from  Single  Sign-on  products)  that  could  extend  the 
DCE  based  capabilities  to  many  different  levels  of  detection  and  response. 

We  believe  that  the  DCE  Registry  can  hold  information  relevant  to  the  operation  of  an  IDS  and 
would  present  a  natural  location  to  hold  "resource  sensitivity"  information.  Using  Extended  (user) 
attributes  in  the  Registry,  we  believe  we  could  set  policies  and  effect  responses  that  an  IDS 
would  take. 

We  believe  another  commercial  grade  IDS  product  is  needed  and  would  be  well  received  in  the 
market  place  where  DCE  is  being  used.  Our  key  differentiators  are; 

1)  Provision  of  an  enterprise-wide  solution  detecting  anomalies  on  most  modern  operating 
systems. 

2)  Provision  of  an  immediate  response  facility  affecting  each  of  those  operating  systems 
listed  above.  The  response  shall  be  implemented  across  one  thousand  systems  within 
one  second. 

3)  Focusing  much  effort  in  the  area  of  elimination  of  “false  positive”  indications  of  intrusion 
(through  use  of  multiple  independently-developed  Intrusion  Detection  engines  and 
refinement  of  those  engines,  rather  than  invention  another  ID  engine). 
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^  secure  industry-standard  security  and  communications  infrastructure  (DCE 
RPC),  therefore  saving  time  that  otherwise  wouid  be  needed  for  creation  of  a  security 
and  communications  infrastructure. 

5)  Implementing  the  forthcoming  Common  Intrusion  Detection  Framework  (CIDF)  to 

facilitate  re-useability  of  components  and  interoperability  with  other  Intrusion  Detection 
products. 

6)  Leveraging  the  scalable  DCE  infrastructure  (which  supports  tens  of  thousands  of  clients 

in  a  single  cell)  by  interfacing  with  the  DCE  Audit  Service.  This  audit  service  only  audits 
security-related  events  and  can  therefore  support  a  cell  encompassing  very  large 
numbers  of  clients.  y 


Page  40 


Printed  01/19/98 


5  Conclusions 


The  effort  of  the  Phase  I  SBIR  has  been  more  successful  than  anticipated.  The  proof  of  concept 
work  undertaken  has  validated  that  our  novel  approach  to  creation  of  an  Intrusion  Detection 
solution  is  feasible  within  the  timeframe  of  Phase  II.  We  now  know  that  we  can  use  some 
proportion  of  existing  technologies  combined  with  new  and  original  work  to  develop  a  viable 
commercial  grade  IDS  product  with  the  key  differentiators  indicated  in  section  4  above.  We  seek 
the  opportunity  to  move  into  Phase  II  and  engage  in  full  scale  development  activities. 


Printed  01/19/98 


Page  41 


This  page  intentionally  left  blank 


Page  42 


Printed  01/19/98 


References 


6 

1 .  Aurobindo  Sundaram.  An  Introduction  to  Intrusion  Detection 
http://www.acm.oro/crossroads/xrds2-4/intrus.html 

2.  Steven  E.  Smaha,  Haystack:  An  Intrusion  Detection  System,  Proceedings  of  the  4th 
Aerospace  Computer  Security  Applications  Conference,  Dec.  1988,  pp37-44. 

3.  Teresa  F.  Lunt  Automated  Audit  Traii  Anaiysis  and  intrusion  Detection:  A  Survey.  11**' 
National  Computer  Security  Conference,  October  1988,  Outstanding  Paper  Award. 

4.  Teresa  F.  Lunt..  IDES:  An  intelligent  system  for  detecting  intruders.  In  Proceedings  of  the 
Symposium:  Computer  Security,  Treat  and  Countermeasures,  Rome,  Italy,  November  1990. 

5.  Teresa  F.  Lunt  and  Debre  Anderson.  Software  Requirements  Specification:  Next-Generation 
Intrusions  Detection  Expert  System  (NIDES)  March  1993,  Computer  Sciences  Laboratory, 
SRI  International,  Meno  Park,  CA  94025  produced  under  U.S.  Government  contract  number 
N00039-92-C-001 5  funded  by  the  U.S.  Navy  SPAWAR. 

6.  Sandeep  Kumar,  Intrusion  Detection  in  Our  Time,  paper  at  the  1994  National  Computer 
Security  Conference,  see  http://www.cs.purdue.edu/coast/coast-tools.html. 

7.  X/Open  Distributed  Audit  Service  pCDAS)  Specification  as  described  and  maintained  by  the 
Open  Group  at:  http://www.rda.openaroup.oro/public/tech/securitv/das/index.htm 

8.  X/Open  Single  Sign-On  (SSO)  Specification  as  described  and  maintained  by  the  Open  Group 
at:  http://Www.rdo.openaroup.ora/public/tech/securitv/sso/index.htm 

9.  IBM  Global  Sign-On  White  Paper  at:  http://www.networkina.ibm.com/aso/ssowpaper.html 

10.  PC-DCE  from  Gradient  Technologies  at: 
http://www.oradient.com/Products/Pc-dce/pcdce  front.htm 

1 1 .  IBM  DCE  products  at:  http://www.networkina.ibm.com/dce/dceprod.html 

12.  IBM  Global  Sign-On  products  at:  http://www.networkino.ibm.com/sso/ssohome.html 

13.  HP  DCE  products  at:  http://www.hp.com/asv/dce/products.html 

14.  Transarc  DCE  products  at: 

http://www.transarc.com/afs/transarc.com/public/www/Public/ProdServ/Product/index.html 

15.  SnareWorks  from  IntelliSoft  at:  http://www.isoft.com/snare/ 

16.  Hacker  Web  Page  at:  http://www.sonic.net/~z/a-h.shtml 

17.  Hacker  Web  Page  at:  http://www.czimmermann.com 

18.  Hacker  Web  Page  at:  http://www.aaate.net/~krees/philes.html 

19.  Hacker  Web  Page  at:  http://www.nih.com/latest/9706 

20.  Hacker  Web  Paoe  at:  http://oliver.efri.hr/~crv/securitv/buas/list.html 

21 .  Hacker  Web  Page  at:  http://www.parodius.eom/~splice/rush/exploits.2/sploits.html 

22.  Hacker  Web  Page  at:  http://www.cvberstreet.com/users/rellik/diebamev 

23.  Hacker  Web  Page  at:  http://www.hardlink.com/~blackout/hackina 

24.  Hacker  Web  Page  at:  http://seclab.cs.ucdavis.edu/proiects/vulnerabilities 


Printed  01/19/98 


Page  43 


This  page  intentionally  left  blank 


Page  44 


Printed  01/19/98 


Appendix  A  -  Components  of  DCE 

Since  DCE  provides  security,  directory,  and  RPC  technologies,  it  aids  in  the  actual  development 
of  a  distributed  intrusion  detection  system.  Further  is  offers  a  unique  vantage  point  from  which  to 
detect  intrusions. 

DCE. Based.Rempte  Procedure  CaH^^^ 

bcE's  RPC  mechanism  is  a  powerful,  secure,  and  interoperable  technology  which  enables 
applications  such  as  an  intrusion  detection  system  to  be  written  and  execute  across  a  wide 
variety  of  platforms.  While  there  are  many  RPC  technology  choices  in  the  market  place  today, 
DCE  has  a  unique  heritage  of  being  developed  through  a  consortium  of  vendors  in  a  fully  "open" 
way  with  primary  sponsorship/development  from  The  Open  Group.  A  little  known  fact  is  that 
Microsoft  used  DCE  RPC  as  the  basis  for  their  Common  Object  Model  (COM)  and  Distributed 
Common  Object  Model  (DCOM)  work.  DCE  RPC  performance  compares  favorably  with  any 
other  RPC  technology,  and  offers  far  more  richness  in  feature  set  thorough  the  addition  of  various 
security  options  as  mentioned  previously. 

.DCE.Securi1y..Seryices 

Second  oniy  to  the  RPC  mechanism,  the  DCE  Security  Service  is  the  most  attractive  feature  of 
DCE.  While  initially  based  on  MIT’s  Kerberos  Version  5  and  HP/Apollo’s  Centralized  Password 
Registry,  significant  enhancements  have  been  made  over  the  last  eight  years.  With  DCE  1.1  the 
Registry  Services  was  enhanced  to  support  Extended  Registry  Attributes  (ERAs)  which  make  the 
Registry  an  extendable  centralized  resource.  The  Authentication  Service  performs  the  function 
necessary  to  validate  the  identity  of  resources  within  the  cell.  This  service  has  been  enhanced 
such  that  at  no  time  is  any  authentication  information  sent  across  the  network  that  is  not  fully 
encrypted  with  strong  encryption  keys.  The  Privilege  Service  has  been  enhanced  to  ensure  that 
no  one  (not  even  the  client)  can  compromise  the  integrity  of  the  certificates  of  authenticity 
(EPAC).  This  makes  the  DCE  Security  Service  an  extremely  robust  and  reliable  technology.  As 
such,  it  is  often  a  primary  factor  in  choosing  DCE  technology  where  high  security  is  needed. 

The  DCE  Security  Service  is  implemented  with  technology  choices  in  mind.  Most  commonly  this 
is  implemented  as  a  centralized  and  replicated  database.  Some  vendors  (e.g.  IBM)  have 
improved  the  database  structure  to  be  stored  in  a  common  database  type  (e.g.  DB2).  The  use  of 
the  DCE  Security  Services  is  tightly  integrated  with  the  DCE  RPC  mechanism. 

Since  the  Security  Service  is  centralized,  we  need  only  to  audit  the  centralized  server  for  security 
related  events  in  order  to  see  the  "whole  cell".  For  an  intrusion  detection  system,  this  greatly 
simplifies  the  challenge  in  seeing  widespread  attacks  throughout  an  environment.  It  also  means 
that  responses  made  within  the  centralized  Registry  are  seen  throughout  the  entire  environment. 
This  simple  fact,  makes  a  DCE  based  intrusion  detection  system  a  compelling  choice. 

.DCE.P|.re.c.tonr.Se.ryi.ces 

DCE  offers  a  standards  based  naming  and  directory  service  that  enables  distributed  applications. 
Servers  are  able  to  "advertise"  their  services  and  clients  able  to  locate  the  servers  in  a  dynamic 
way.  This  allows  servers  to  "come  and  go",  as  would  be  expected  in  a  dynamic  system,  without 
clients  loosing  the  capability  to  locate  a  server  that  can  service  their  request.  As  was  illustrated  in 
the  "Consolidating  Audit  Service  Events  Across  Multiple  Systems"  section  above,  this  service 
allows  an  application  to  be  designed  such  that  locality  of  reference  and  priority  of  servers  can  be 
taken  into  account  for  a  rich  fault-tolerant  application  architecture. 

The  DCE  Directory  Service  is  implemented  with  technology  choices  in  mind.  Most  commonly 
used  is  the  DCE  Cell  Directory  Service  (CDS)  which  is  implemented  as  a  centralized,  partitioned 
and  replicated  database.  It  can  also  be  integrated  with  a  more  global  directory  service  such  as 
Domain  Name  Service  (DNS)  or  X.500  Directory  Services.  The  use  of  the  Directory  Service  is 
tightly  integrated  with  the  DCE  RPC  mechanism. 
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P.QE  Time  Services 

It  is  critical  in  a  distributed  environment  that  system  clocks  are  properly  synchronized.  Without 
proper  synchronization,  valuable  data  may  be  corrupted  or  misleading  infomnation  given  to 
unsuspecting  users.  DTS  prevents  this  from  happening  by  synchronizing  the  clocks  across  the 
cell.  To  this  end,  DTS  provides  administrators  with  a  variety  of  methods  to  achieve  clock 
synchronization.  Options  include  obtaining  a  time  value  from  an  external  source  and  an  algorithm 
based  on  sampling  the  clocks  in  the  cell.  Most  important  is  that  time  always  moves  forward 
(never  backward)  which  is  achieved  with  modification  of  the  operating  system's  interaction  with 
the  hardware  clock. 

DCE/pFSDjstnbuted.Fjle  Services 

DFS  is  the  distributed  file  sysiem  that  is  offered  with  DCE.  It  is  a  single  integrated  file  system  that 
can  coexist  with  a  system's  native  file  system.  Chief  among  its  strengths  is  its  tight  integration 
with  pCE.  This  allows  DFS  to  take  advantage  of  authentication  provided  by  the  DCE  Security 
Service.  In  addition  to  this,  DFS  provides  a  more  granular  set  of  file  permissions  than  those 
provided  with  the  UNIX  file  system.  System  administrators  can  be  much  more  precise  when 
defining  permissions  on  sensitive  files  or  directories. 

Also  of  great  value  is  the  excellent  performance  offered  by  DFS.  Caching  is  used  on  the  client 
machine  to  reduce  the  number  of  calls  made  to  the  server.  This  significantly  speeds  file 
operations  as  the  client  only  contacts  the  server  when  absolutely  necessary. 

DFS  offers  an  excellent  file  replication  facility  which  allows  a  certain  degree  of  fault  tolerance  from 
a  network  failure.  Should  a  particular  mount  point  fail,  DFS  can  automatically  re-establish  contact 
with  a  replica.  This  transfer  remains  invisible  to  the  user  and  results  in  no  lost  productivity. 

The  systems  administrator's  duties  are  simplified  by  an  excellent  data  movement  facility  which 
enables  user  data  to  be  moved  from  file  server  to  file  server  even  which  the  file  is  open  and 
actively  being  written  to. 
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Appendix  B  -  Source  Code  to  Programs 


AudjtUsten 

Makefile 

aud.c 

aud.h 

aud_misc.c 

Secure.Broadcast 
Makefile 
myapp.c 
myapp.h 
alanm_a.c 
alarm^a.h 
alarm.a.idl 
alarm_c.c 
alami_c.h 
alarm  c.idi 


Used  to  build  the  auditListen  program 
The  primary  code  to  the  auditListen  program 
The  C  header  to  the  auditListen  program 
Utility  C  code  used  by  the  auditListen  program 

BFC.AItematiye 

Used  to  build  the  client  and  agent  pograms 

General  purpose  code  used  by  both  client  and  agent  programs 

The  C  header  file 

The  primary  code  to  the  agent  program 
The  C  header  file 

The  DCE  Interface  Definition  Language  (IDL)  file 
The  primary  code  to  the  client  program 
The  C  header  file 

The  DCE  Interface  Definition  Language  (IDL)  file 
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Appendix  B  -  auditUsten 

Makefile 

CC  «  gcc 

DCE_INC  -  -1/opt/dcelocal/share  -I/opt/deeloeal/ share/include  - 

I/opt/dcelocal/share/include/doe 

INC_DIR  =  -I .  $  (DCE_INC) 

DEBUG  -  -g 

DIBS  “  $ (LIB_DIR)  —Idee  -laudit  — Itiiread  — Isodcet  -Im 

OBJS  =  aud^nixsc. o  aud^idiot.o  aud.o 

auditliisten:  $  (OBJS) 

$(CC)  -o  auditliisten  $  (OBJS)  $  (LIBS) 

clean: 

xm  -f  *.o  auditliisten 

aud.c 

/* 

*  MODULE:  aud.c 

*  DESCRIPTION: 

*  This  module  contains  the  jpcplementation  of  the  auditliisten  test. 
*/ 

#include  ” aud . h" 


void  main  (int  arge,  char 

{ 

dce_aud_rec_t 

unsigned_char_t 

int 

boolean32 

error_status_t 

pthread_t 

unsigned__chax_t 

FILE 

3cill_Jxandler_t 

long 

long 


**argv) 

ard; 

*buff; 

fd,  i,  listc,  code; 
done; 

St,  st2; 

3cill_tid,  notfy_tid; 
trail_name  [STRING_LEN]  ; 
♦data; 
kill_args ; 

c_trail_pos ,  c_jLndex_pos  ; 
p_trail_pos  ,p_index_pos ; 


new^record 

recycle 

trail^size 

c_trail_pos 

p_trail_pos 

c_index_j)o  s 

p_index_pos 


=  FALSE; 
=  FALSE; 
«  0; 

-=  0; 

*=  0; 

=  0; 

=  0; 


/*  Did  the  user  not  specif  a  trail  file‘> 
*/ 


if  (arge  <  2)  ( 

/*' ERROR:  Audit  trail  file  not  specified.  \n”)  ; 

exit(O); 

> 

strcpy(trail_name,argv[l])  ; 

/♦  Open  data  fdLle  to  cut  audit  informtation  to 
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*/ 

if  ( (data=f  open  ( ”  /  tii5>/audit_data .  log"  , " w" ) )  =  NULL)  { 
fprintf  (stderr, "ERROR:  Cannot  open  the  log  file.\n"); 

> 

/*  Open  audit  trail  file 
*/ 

dce_aud_open(aud_c_trl_open_read,  trail_naxDe,  0,  0,  (dce_aud_trail__t 
*)ttradLl,  4st); 

CHECK__STATUS(st/'dce_aud_open()  FAILED .  \n"  , ABORT)  ; 
cut_d^ug_info (data, "Opened  audit  trail  file."); 


/*  Set  up  Jcill_handler  thread 
*/ 

code  -  sigemptyset  (£iDask)  ; 
if  (code  !=  0)  { 

fprintf  (s tderr , "  sigeinptyset  ( )  FAILED .  \n" )  ; 
f  close  (data)  ; 
exit(l)  ; 

} 

code  =  sigaddset  (£inas]c,SI6INT)  ; 
if  (code  !=  0)  { 

fprintf  (stderr , " sigaddset  ()  FAILED .  \n" )  ; 
f  close  (data)  ; 
exit(l)  ; 

> 

code  sigaddset  (&inask,SI6TERH) ; 
if  (code  !=  0)  { 

fprintf  (stderr,  "sigaddset  ()  FAILED.  \n" )  ; 
f  close  (data)  ; 
exit(l) ; 

} 

code  =  sigprocmask(SI6_BLOCK,£]nask,NULL)  ; 
if  (code  ?*  0)  { 

^rintf  (stderr , "  sigprocmask  ()  failed  .  \n" )  ; 
f  close  (data)  ; 
exit(l)  ; 

kill^args .  trail  =  (dce__aud_trail__t)  trail  ; 
kill_args.log  *  data; 

code  =  pthread_create(&kill_tid,pthread_attr_default, 
(pthread_startroutine_t)  kill_handler , 
(pthread_addr_t)  £kill_args) ; 
if  (code  !*  0)  { 

^rintf  (stderr ,  "pthread^^create  ( )  FAILED .  \n" )  ; 
f  close  (data)  ; 
exit(l)  ; 

> 

/*  Noti:^  of  new  records  appended  to  trail  file 
*/ 

code  =  pthread_create(&not^_tid,pthread^attr_default, 
(pthread_startroutine_t)  notify_of_new_records , 
(pthread_addr_t  *)  trail_na]ne)  ; 
if  (code  !=  0)  { 

^rintf  (stderr ,  "pthread^create  ( )  FAILED .  \n" )  ; 
f  close  (data)  ; 
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} 


exit(l)  ; 


/*  Read  records  from  the  file 
*/ 

while  (1)  { 

if  (recycle)  { 

/*  Close  and  reopen  trail  file  because  we  detected  some 

operation 

that  shrunk  the  size  of  the  trail  file  such  as: 

**  (1)  aud  trail  file  rollong  over  after  hitting  mav  size. 

**  (2)  user  executing  dcecp  -c  aud  rewind 


dce_aud_close ( (dce_aud_trail_t)  trail,  tst)  ; 
CHECK_STATUS  (st,  ''dce_aud_close ()  FAILED.  \n”  , ABORT)  ; 
dce_aud__open  ( aud^c_t rl_open__read ,  trail  name,  0 ,  0 , 
(dce_aud_trail_t  *)  4 trail,  ist)  ;  “ 

CHECK_STATUS  (st ,  " dce_aud_open  ( )  FAILED .  \n"  , ABORT)  ; 
cut_debug_info (data, "Rewound  the  audit  log."); 

recycle  =  FALSE; 
c_trail_pos  =  0; 
c_index_pos  =  0; 

> 

if  (new^record)  { 
done  =  FALSE; 
while  ( ! done)  { 

/*  Get  next  record 
*/ 


(^®_^^d_trail_t)  trail,  NULL,  0,  4ard,  fist)  ; 
CHECK_STATUS  (s t ,  "dce_aud_next  ()  FAILED .  \n"  , ABORT)  ; 

p_trail_j>os  «  c_trail^os; 
p_index_pos  *  c_index_pos; 

c_trail^jpos  *  f tell  (trail- >trail_fp)  ; 
c__index_pos  «  f tell  (tr ail- >md_index__fp)  ; 

if  (ard  =  NULL)  { 

dce_aud_backup  (trail  ,p_trailjpos  ,p_index_pos ,  fist)  ; 
CHECK_STATUS  (s t ,  "  dce_aud_bac3ciip  ( )  FAILED .  \n”  , ABORT)  ; 

done  «=  TRUE; 
new_record  =  FALSE; 
break; 

} 

/*  Cut  record  information  to  data  file 
*/ 

if  (USE_IDIOT)  { 

convert_to_idiot(ard)  ; 

) 

cut_record_info( ard, data) ; 


/*  Release  memory  for  record 
*/ 
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dce^^aud^di scard  ( ard ,  4s t)  ; 

CHECK_STATUS  (s t ,  ”dce_a\Ki_discard  ()  FAILED .  \n"  , ABORT)  ; 

> 

> 

} 

) 

aud.h 

#ifndef  _AUD_H 
#define  _ADD_H 

/* 

*  MODULE:  aud.h 

* 

*  DESCRIPTION: 

*  This  module  contains  prototypes  and  definitions  used  In  the 

*  tes tease  audltProbe,  used  to  show  the  records  In  the  audit  trail. 

* 

*/ 

/*  INCLUDE  FILES  */ 

#lnclude  <dce/dce.h> 

#lnclude  <dce/dce_^g.h> 

#lnclude  <dce/ audit. h> 

#lnclude  <dce/audlt_control .  h> 

#lnclude  <dce/dce_error .  h> 

#lnclude  <dce/dceaudmsg.h> 

#lnclude  <stdlo.h> 

#lnclude  <stdllb.h> 

#lnclude  <strlng.h> 

#lnclude  <fcntl.h> 

#lnclude  <pthread.h> 

#lnclude  <slgnal.h> 

#lnclude  <sys/stat.h> 

#lnclude  <sys/ types. h> 

/*  DECLARATIONS  */ 

#def  Ine  ABORT  1 

#deflne  RESUME  0 

#deflne  STRING_LEN 
#deflne  USE_IDIOT 

/*  MACRO  DEFINITIONS  */ 


#deflne  CHECK^STATUS  (Iz^ut^status,  comment,  action)  \ 

{  \ 

If  (Input^status  !*  aud^s^olc)  {  \ 

dce_error_lng_text(li:5>ut_status,  error  string,  4error  stat)  ; 

\  "  ” 

^rlntf  (stderr ,  ”%s  %s\n”  ,  comment,  error__strlng)  ;  \ 

If  (action  **  ABORT)  (  \ 

exlt(l);  \ 

)  \ 

>  \ 

} 


/*  VARIABLE  DECLARATIONS  */ 
static  Int  error_stat; 

static  unsigned  char  error_strlng[dce_c_error_strlng_len] ; 


2000 
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sigset_t 

off_t 

boolean32 

boolean32 


mask; 

trail__si2e; 

new^record; 

recycle; 


/♦  TYPEDEF  DECLARATIONS  */ 


tyx>edef  struct  a\id_trail_handle  { 
int  location; 

xpc^binding_handle_^t  auditd  binding; 
char  *trail~file; 

int 


FILE 

char 

int 

FILE 

int 

FILE 

unsigned32 
unsigned32 
unsigned32 
boolean32 
unsigned32 
pthread^mutex^t 
}  aud  trail  t; 


trail^fd; 

*trail_fp; 

*index_file; 

index_fd; 

*index_fp; 
ind_index_fd; 
*nid_index_fp ; 
index^cursor ; 
tr ail_cur s  or ; 
flags ; 

f ile^siz  e^limi  t ; 
f ile_size_liini  tjralue  ; 
mutex; 


typedj&f  struct  3cill_handler_type  { 
dce_aud_trail_t  trail; 

FILE  *log; 

}  kill^handler^t ; 

/*  PROTOTIEES  */ 


void  kill_handler  (kill_handler_t  *args)  ; 

void  notify_of_new_records  (unsigned_char_t  *trail_naxne)  ; 

#endif 


aud_misc.c 

*  MODX7LE :  aud^misc .  c 

* 

*  DESCRIPTION: 

*  This  module  contains  misc  fuctions  used  by  the 

*  auditListen  test. . 

* 

*/ 


void  cut_record_inf o  (dce_aud_rec_t  ard,  FILE  ♦log) 

dce_atid_hdr_t  *header; 
error__status_t  st; 
struct  tm  tmevnt; 

/*  Get  header  from  record 
♦/ 

dce_aud__get_header  (ard,  ^header ,  As t)  ; 

CHECK_STATUS  (st /*dce_aud_get_header  ()  FAILED.  \n”  , ABORT)  ; 

/♦  Get  time  information 
*/ 
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utc_ai^tijne  ( Atanevnt ,  0 , 0 , 0 , 0 ,  £  (header- >tiine) )  ; 

/*  Cut  record  information 
*/ 

^rintf  (log/*->  %d-%02d“%02d-%02d:%02d:  %02d  <-  event:  %d\n"  , 
tmevnt.  tm_year+1900 , 
tmevnt .  tm_mon+l , 
tmevnt .  tm_jnday , 
tmevnt.  tm__hour, 
tmevnt.  tm_iiiin, 
tmevnt .  tm^sec , 
header- >event) ; 
f  flush  (log)  ; 


void  cut_d^ug_inf o  (FILE  *log,  char  *string) 

{ 

utc_t  time; 
struct  tm  tmevnt; 

/*  Get  time  information 
*/ 

utc_gettime(£time)  ; 

utc_anYtime  (£t3nevnt , 0 , 0 , 0 , 0 ,  £time)  ; 

/*  Cut  record  information 
♦/ 

^rintf  (log/'->  %d-%02d-%02d“%02d:  %02d:  %02d  <-  %s\n”  , 

tmevnt .  tm_year+1900 , 
tmevnt .  tm_mon+l , 
tmevnt .  tm_mday , 
tmevnt.  tm^hour, 
tmevnt .  tm_min , 
tmevnt .  tm_sec , 
string)  ; 
f  flush  (log)  ; 


void  kill^handler  (kill^handler  t  *args) 

{ 

int  sig; 

error_status_t  st; 

sig  »  sigwait(£mask) ; 
if  (sig  =  -1)  { 

fprintf  (stderr,"sigwait()  FAILED. \n")  ; 
exit(l); 

} 

^rintf  (stderr,"\n’^**  Got  Signal  %d  ♦**\n"  ,  sig)  ; 

/*  Close  the  aud  trail  file 
*/ 

^rintf  ( 8 tderr,  "Closing  audit  trail  file.\n”)  ; 
dce_aud_close(args->trail,  £st); 

CHECK_STATUS(st/'dce_aud_close()  FAILED. \n"  ,ABORT)  ; 
cut_debug_info(args->log, "Closed  audit  trail  file."); 

/*  Close  the  log  file 
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*/ 

fprintf  (stderr,  "Closing  the  log  file  /tii5>/audit_data.log\n")  ; 
fclose  (args->log) ; 
exit(l)  ; 


void  noti^_of_jiew_records  (nnsigned_char_^t  *trail_nanie) 

int  code; 

struct  stat  buf  ; 

while  (1)  { 

code  =  stat(trail_naine,fibuf)  ; 
if  (code  !=  0)  { 

^rintf  (stderr,  "statO  FAILED . \n" )  ; 
exit(l)  ; 

> 

if  (buf.st_size  >  trail^size)  { 
new^record  =  TRUE; 
trail_size  =  buf.st_size; 

}  else  if  (buf.st_size  <  trail^size)  { 
recycle  =  TRUE; 
trail  _size  *=  0 ; 

} 

) 

) 

void  dce_aud__backup  (aud^trail__t  trail, 
long  t_j>osition, 
long  imposition, 
error_statuSm_t  *  status) 

{ 

int  code; 

trail .  trail^cursor  =  t^position; 

code  =  fseelc(trail.  trail_^,tmPosition,SEEK  SET)  ; 

if  (code  0)  ( 

fprintf  (stderr,"dce_audmbacki:5>()  fseek  failed. \n” )  ; 

^status  ■=  1; 

return; 

) 

code  «  fseek (trail.iiidmindex_fp,i_j)osition, SEEK  SET)  ; 
if  (code  ?=  0)  { 

^rintf  (stderr,”dce_aud_backi^()  fseek  failed.  \n"); 

*status  «  1; 

return; 

> 

♦status  *  aud  s  ok; 
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Appendix  B  -  Secure  Broadcast  RPC  Alternative 

Makefile 

#  make  file  for  alarm  agent  and  alarm  client 
CC  =  g++ 

GCC  «  gcc 

COPTS  =  -g 

DEFINES  -D_SUN 

6CC_INC  == 

DCE_INC  =  -I/opt/dcelocal/share  -I /opt/dcelocal/ share/include  - 
I  /  op  t/dcelocal/share /include /dee 

INC  «  -I.  ${DCE_INC}  ${GCC_INC} 

LDFLAGS  =  -Idee  -Im  -Ithread  -Isocket 
CFIA6S  =  $ (COPTS)  $  (DEFINES)  $ (INC) 

IDLC  =  idl 

IFIAGS  =  -cc^cml  $(CC)  -CC_opt  ”-C  $  (COPTS)  $  (DEFINES)  ” 
default: 

6 echo  "Please  specif  a  target." 

all:  alarm 
IF1=  alaxm^c 
IF2=  alazm^a 

myc^p.o:  niYapp.h 
alarm:  aym  c  a-rm  SL 

alam^c:  alaxm_c.o  nyapp.o  $  (IF2)_cstub.  o  $  (IFl)_sstub.o 

$(CC)  $(CFIA6S)  -o  alarm^c  alarm^^c.o  nyapp.o  $ (IF2)_cstub. o 
$(IFl)_sstub.o  $(IiDFIAGS) 
alam^c.o:  alaxm__c.h  alarm^a.h  syapp.h 

alam^a:  alarm_a.o  nyapp.o  $  (IF2)_sstub.  o  $  (IFl)_cstub.o 

$(CC)  $(CIiFAGS)  -o  alaxm_a  alarm^a.o  nyapp.o  $ (IF2)_sstiib. o 
$(IFl)_cstub.o  $(IiDFIAGS) 
alam^a:  alaxm^a.h  alarm_c.h  nyapp.h 

$(IFl)_cstub.o  $(IFl)_sstub.o  $(IF1)  .h:  $(IFl).idl 
$(IDLC)  $  (IFIAGS)  $(IFl).idl 

$(IF2)_cstti).o  $(IF2)_sstub.o  $(IF2)  .h:  $(IF2).idl 
$(IDLC)  $ (IFIAGS)  $(IF2).idl 


.myapp.-c 

extern  "C"  { 

#±nclude  <stdlib.h> 

> 

#lnclude  ”nycg>p.h” 

#def ine  DEBUG  1 

//  definition  of  class  DCE_server  first 
//  DCE_server : :  DCE^server  ( ) 

//  select  protocol  sequence 
//  inquire  server  binding 
It  register  with  enc^oint  matp 
1 1  export  binding  to  name  space 
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/  /  sett^>  management  thread  to  refresh  Identity  before  expired  and  key 
//  management 
//  listen  to  client  calls 
// 

DCE_server;  :DCE_server( 
rpc_lf_handle_t  Ih, 
imslgned_char_t  *  prln, 
uuld_t  *incrr_type_uuld, 
rpc_jiigr_epv_t  mgr^epv, 

Myproto  p, 

Int  authn^lgn, 
unslgned32  protection, 

\mslgned32  authn, 
iinslgned32  authz , 
imslgned_char_t  *  kt, 

Int  ep, 

Int  ns, 

Int  ls_llsten 

) 

:lf_handle(lh)  ,  principal  (prln)  ,  mgr_type_unld_of_ob  j  (mgr_type_uuld)  , 
nianager_epv(mgr_epv)  ,  ]iyproto(p)  , 

authn_login(aiathn_lgn)  ,  protectlonJLevel  (protection)  , 
authentication  (authn)  ,  authorization  (authx)  ,  k€ytab_flle(kt)  , 
enc^olnt(ep)  ,  naiiie_space  (ns)  ,  server_entry  (0)  ,  groi5>_entry  (0)  , 
proflle_entry(0)  ,  refresh__id_thread(0)  , 
keyjmgmt_thread(0)  ,  slgcatch_thread(0) 

{ 

use_j)rotocol  ()  ; 

If  (DEBUG)  cout  «  ”  use_protocol  conpleteXn” ; 
lng_server_blndlngs  ()  ; 

If  (DEBUG)  cout  «  “  Ing^server^blndlng  complete\n" ; 

If  (authn__logln)  sec_logln()  ; 

If  (DEBUG)  cout  «  "  authn^logln  completeXn" ; 

register_interface()  ; 

If  (DEBUG)  cout  «  ”  reglster_jLnterf ace  completeXn”  ; 

If  (^)  register_endpolnt()  ; 

If  (DEBUG)  cout  «  ”  reglster^endpolnt  completeXn” ; 

If  (ns)  e3g>ort_to_naiiiespace()  ; 

If  (DEBUG)  cout  «  "  export^to^namespace  conpleteXn" ; 

If  ( authn^logln)  s tar t_ingmt_thread ( )  ; 
start_slgnal_thread()  ; 

If  (ls_llsten)  listen  0  ; 

} 

it  DCE_server:  : listen () 

//  FUNCTIONALITY: 

it  start  to  listen  Incoming  calls 

// 

void  DCE_server:  :11s  ten  0  { 

cout  «  "server  "  «  principal  «  "  Is  listening"  «  endl; 
rpc_server_llsten(rpc_c_llsten_jnax_calls_default,  4status)  ; 
dce^error (status,  "server  stop  listening. . .") ; 

> 
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//  DCE_server:  :use_protocol  0 
//  FUNCTIONALITY: 

//  select  u<^,  tcp  or  both 

// 

void  DCE_server;  :use_protocol()  { 
switch  (n^roto)  { 

case  an  :  { rpc_server_use_all_j>r otseqs  ( 

rpc__cjprotseqjnax_reqs_defaiilt,  ^status)  ; 

dce_error (status ,  ” rpc_server_use_all3>rotseqs  failed" ) ; 

break; 

> 

case  ndpi  {rpc_server_use_protseq( 

(unsigned_char_j)_t)  "ncadqjLp^udp"  , 
rpc_c_protseq_inax_reqs_default,  ^status)  ; 
dce_error (status,  "rpc_server__use_proteseq  udp  failed”); 
break; 

} 

case  tcp:  {rpc_server_use_j>rotseq( 

(unsigiied_char_p_t)  ”ncacii_ip_tcp"  , 

rpc_c_j>rotseqjnax_reqs_default,  ^status)  ; 

deeper ror (status,  ”rpc_server_use_j>rotseq  tcp  failed")  ; 

break; 

) 

} 

} 


//  DCE_server:  :iiiq_server_bindings  0 
//  FUNCTIONALITY: 

//  wrapper  for  rpcjLnq_binding  to  get  server  binding  vector 

// 

void  DCE^server:  :inq_server_bindings  0  { 
rpc_server_inqjDindings  ( 4bv,  £status)  ; 
dce_error (status ,  "Unable  to  get  server  bindings”); 

} 


//  DCE^server:  :register^interface() 

//  FUNCTIONALITY: 

//  wrapper  for  rpc_server_register_if  to  register  interface 
ft  specification  with  RPC  runtime 
// 

void  DCE_server:  :register_interface()  { 

rpc_server_j:egister__if  ( 

if^handle, 

ingr_type_uuid_of_ob  j , 

]nanager_epv , 

(status) ; 

dce_error (status,  "Unable  to  register  server  interface  with  RPC 
runtime")  ; 

> 

//  DCE^server:  :register_enc^oint  0 
//  FUNCTIONALITY: 
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//  wrapper  for  rpc_ep_reg±ster  ()  to  register  with  endpoint  mapping 
interface 
// 

void  DCE^server:  :register_enc^oint  ()  { 
rpc_ep_register  ( 
if_handle, 
bv, 

NULL,  //  obj  unid 
(tinsigned_char__t  *)  principal, 

^status)  ; 

dce_error (status,  "Unable  to  register  with  enc^oint  map")  ; 

/ /  DCE^server : :  e3g)ort^to_namespace  () 

//  FUNCTIONALITIES: 

//  export  the  server  binding  to  name  space 
//  PREREQUISITE: 

//  ENVIRONMENT  VARIABLE 
//  SERVER^ENTRY :  server  entry  in  CDS 
//  GROUP^ENTRY:  group  of  server  entry  in  CDS 
/ /  PROFILE_ENTkY :  profile  of  groi^  entry  in  CDS 

void  DCE__server:  :e3g>ort  to  namespace  ()  { 
const  int  SIZE  =  25^  "" 

if  (DEBUG)  cout  «  "  start  to  allocate  memory  for  server__entry\n"  ; 

server^entry  =  new  unsigned_char  t  [SIZE] ; 
groxQ>_entry  =  new  unsigned_char_t  [SIZE] ; 
profile_entry  =  new  unsigned_char_t  [SIZE]  ; 


char  *  server_teiEp  =  NULL; 

char  *  groiq>_teiDp  =  NULL; 

char  *  profile^tenqp  =  NULL; 

if  (server^tenop  =  getenv("SERVER__ENTRY”) ) 

strcpy  ( (char  ’^)  server__^entry ,  server^tenp)  ; 

if  (groiQ>_teiDp  =  getenv("GROUP_ENTRY”) )  { 
strcpy  ((char  *)  groi^^entry ,  groi:5)_teiDp)  ; 
if  (DEBUG)  cout  «  "tenp  is  not  NULL\n"; 

} 

if  (profile_teiDp  =  getenv("PROFILEJENTRY”) )  { 
strcpy  ((char  *)profile_entry ,  profile  tenp)  ; 
if  (DEBUG)  cout  «  "  tenp  is  not  NULL\n” ; 

> 

if  (DEBUG)  { 

cout  «  "start  to  export  to  namespace\n"  ; 
cout  «  "server_entry:  "  «  server_entry  «  endl; 
cout  «  "gro\p__entry:  "  «  grotp_entry  «  endl; 
cout  «  "profile_entry:  "  «  profile_entry  «  endl; 


rpc_ns_binding_export  ( 

rpc_c_ns_syntax_def  aid  t , 
(unsigned__char jp_t)  server_^entry , 
if_handle, 
bv, 

NULL,  //  object  UUID 
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^status) ; 

dce^^error (status ^  "Unable  escort  to  name  space")  ; 
if  (DEBUG)  cout  «  "  rpc_^ns_binding_eaq>ort  coiopleteNn" ; 

if  (group^tenp)  { 

rpc^ns^groiqp^jnbr^add  ( 

rpc_c_ns_syntax_def  ault , 

(unsigned_charjp_t)  groi^^entry, 
rpc^c^ns^syntax^def  ault , 

(unsigned__char^_t)  server_entry , 

£status)  ; 

dce^error (status,  "Unable  e3q>ort  to  group  entry"); 

} 

if  (DEBUG)  cout  «  "  rpc_ns__groi5>_iiibr__add  completeXn" ; 
if  (profile^tenp)  { 

rpc_if_inq[_id  (if^handl  e ,  4if_id,  &  status)  ; 

dce_error (status,  "Unable  to  get  interface  identifier"); 

rpc_ns jprof ilejelt_add  ( 

rpc_c_ns_syntax_def  aul  t , 

(unsigned_char_p__t)  prof ile_en try, 
tif_id, 

rpc_c_ns_syntax_def ault , 

(unsigned_char_p_t)  server^entry , 

0 ,  //  priority 

(unsigned_char_j>_t)  principal,  //  annotation  actiially 
4status) ; 

dce_error (status ,  "Unable  export  to  profile  entry"); 

) 

) 

//  DCE^server:  :sec_login() 

//  FUNCTIONALITY: 

//  aetxxp  server  principal  identity 

//  validate  and  certify  the  server  principal '  s  identity 
//  setup  security  login  context 

//  server  register  authentication  information  with  RPC  runtime 

// 

void  DCE^server:  :sec_login()  { 
seti5>_identity  0  ; 
valid_and_cert_identity  0  ; 

sec^login^se t^context  ( login^context ,  L  s  tatus )  ; 
dce_error (status,  "Unable  to  sett^)  server  login  context"); 

rpc_server_register_auth_inf  o  ( 
principal , 

rpc_c_authn_dce__secret , 

NULL,  //  use  default  key  tab  retrieval  niethod 
k^tab__f  ile , 

^status)  ; 

dce^error  (status ,  "Unable  to  register  server  auth  info  with  RPC 
runtime") ; 

> 

//  DCE_server:  :setT^_identity  0 
//  FUNCTIONALITY: 

//  wr^per  for  sec_login_setup  identity  () 

// 

void  DCE^server:  :set'i:5>_identiiy  0  { 
sec_login_setup_identity  ( 
principal , 
sec_login_no_f lags , 
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£log±n_^context , 

^status) ; 

dce^error (status ,  "Unable  to  seti^>  Identity  for  server  principal"); 

} 

//  DCE_server:  :valld^and_cert_identlty  0 
//  FUNCTIONALITy: 

//  get  server  key 

//  validate  the  server's  Identity 

//  free  server  key  to  make  stire  no  one  have  enough  timg*  to  get  server 
key 

//  certl^  the  server's  Identity 

// 

void  DCE_server:  :  valld_and_cert_ldentlty  ()  { 

void  *  key^data; 

sec_login_auth_src_t  authn_src ; 

boolean32  reset_pas sword; 

sec__key_nigmt_get_key  ( 

rpc__c_authn_dce_secret , 

(unslgned_char_j>_t)  keytab_flle, 

(unslgned_char_j>_t)  principal, 

0,  //  latest  k^  version 
&key_data, 

^status)  ; 

dce^^error (status,  "Unable  to  locate  server  key")  ; 

sec_logln__valldate_identlt^  ( 
logln__context , 

(sec_j>asswd_rec_t  *)  key_data, 

£reset_j>as  sword , 

&authn_^src , 

^status) ; 

deeper ror (status,  "Unable  to  validate  Identity")  ; 

sec_keyjngmt_free_key(key_data,  ^status)  ; 

dce_^error (status ,  "Unable  to  free  server  key"); 

sec_login_certlfy_ldentlty  ( 
logln^context , 

(status) ; 

dce_error (status,  "Unable  to  certl^  Identity  for  server"); 

) 

/ /  DCE__server :  :  ^DCE_server  () 

//  FUNCTIONALITY: 

//  remove  binding  Information  at  CDS 

//  remove  binding  Information  at  enc^olnt  mapping  service 

//  unregLster  server  binding  Information  from  RPC  runtime 

//  kill  k^  management  thread 

//  IclU  refresh  ID  thread 

//  klU  signal  catcher  thread 

It  purge  security  login  context 

//  free  resouce  acquired 

ft 

DCE_server : :  ^DCE_server  ( )  ( 

rP9_lf_ld_t  lf_ld;  rpc_lf_lnq_ld(lf_handle,  (lf_ld,  (status)  ; 

dce_error (status,  "Unable  to  get  Interface  Identifier"); 

If (proflle_entry)  { 

xpc^ns_prof lle^elt_remove  ( 
rpc_c_ns_syntax_def  aul  t , 
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(\msigned_chaxjp_t)  prof ile_en try , 

rpc_c_ns_syntax_def  ault , 

(misigned_char_j>_t)  server_entry , 

£status)  ; 

dce_error (status,  "Unable  to  remove  entry  from  profile" ,  0); 

> 

if  ( gr oi^_en try )  { 

rpcjas^gro\:5>_inbr^remove  ( 

rpc_c_ns_syntax_def  ault , 

(unsigned_char_j>_t)  groi^_entry, 
rpc_cjis_syntax_def aiil  t , 

(unsigned_char_j)_t)  server_entry , 

^status)  ; 

dce_error  (status ,  "Unable  to  remove  entry  from  gxoi^"  ,  0); 

> 

if  (server^entry)  { 

rpc_ns_binding_unexport  ( 
rpc_c_ns_^syntax_def  aul  t , 

(unsigned_char_j>_t)  server_entry , 
if_handle , 

NULL,  //  should  be  an  object  UUID 
(status)  ; 

dce^error (status,  "Unable  to  unes^ort  server  entry",  0); 

) 

if  (enc^oint)  { 

rpc^epjunregister  ( 
if^handle , 
bv, 

VULL,  //  should  be  an  object  UUID 
(status)  ; 

dce__error (status,  "Unable  to  remove  entry  point",  0); 

} 

rpc_server_unregister_if  ( 
if__handle, 

iiigr__type_uuid_of_ob  j , 

(status)  ; 

if  ()cey_ingmt_thread) 

lcill_thread(k^jBigmt_thread,  "key  management")  ; 
if  (refresh_id_thread) 

kill_thread(refresh_id_thread,  "refresh  identity")  ; 
if  (sigcatch^thread) 

kill_^thread(sigcatch^thread,  "signal  catcher")  ; 
dce^error (status,  "Unable  to  unregister  interface  with  RPC  runtime")  ; 

sec_login_purge_context  ( (login_context ,  (s  tat\is )  ; 

dce^error (status ,  "Unable  to  pturge  server  security  login  context", 

0); 

rpc_binding_vector_f ree  ( (bv ,  (status )  ; 

dce_error (status ,  "Unable  to  free  binding  vector",  0); 

if  (server^entry) 

delete  [  ]  server^entry ; 
if  (group_entry) 

delete  []  group_entry; 
if  (profile_entry) 

delete  []  profile^entry; 

//  if  (mgr_typejuuid_of_obj) 
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//  delete  mgr^type  uuid  of  obj; 


/ /  DCE_server ;  :  start_iiignit_thread 
1 1  FUNCTIONALITT: 

//  start  refresh^identity  thread  to  refresh  identity  periodically 
/  /  start  key  mgmt  thread  to  manage  key 
//  “ 

void  DCE^server:  :  start_mgmt_thread()  { 
create^thread  ( 

ref  resh^^identity , 

"refresh  identity", 

4ref  resh^ic^thread , 

(pthread_addr_t)  this)  ; 

create_thread  ( 
key_mgmt, 

"k^  management" , 
tkey_mgmt_thread , 

(pthread_addr  t)  this)  ; 

} 

//  DCE_server:  :start_signal_thread() 

//  FUNCTIONALITy: 

/ /  setup  signal  handling  for  the  server 

// 

void  DCE_server:  :  start_signal_thread()  { 
create^thread  ( 

signal_catcher , 

" signal  catcher" , 

£  sigca  tch_thread , 

NULL) ; 

} 


//  Helper  function  of  DCE^server 
//  k€y_mgmt() 

//  FUNCTIONALITY: 

//  given  a  server,  manager  this  server's  key 

pthreac^addr^t  key jigmt  (pthread  arfHy  t  arg)  { 
unsigned32  status;  "" 

DCE_server  *  theServer  =  (DCE_server  *)  arg; 

if  (DEBUG)  oout  «  "The  key_iiigmt  thread  is  starting  to  work.  ..\n"; 
sec_key_ingmt_inanage_k^  (  ' 

3TC_c__authn^dce__^secret , 
theServer- >keytab_file , 
theServer- ^principal , 

^status) ; 

dce^error (status ,  "Unable  to  manage  server  keys")  ; 

//  refresh_identi1y 
//  FUNCTIONALITY: 

//  given  a  server,  refresh  the  server's  identity  periodically 

pthread_addr_t  ref resh_identity  (pthread  addr  t  arg)  { 
timeval  now;  ^ 

timespec  sle^^time; 
unsigned32  expiration; 
unsigned32  status; 

DCE_sej:ver  *  theServer  =  (DCE_server  *)  arg; 
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±f  (DEBUG)  cout  «  "the  refresh_ident±ty  thread,  is  starting  to 
work. . . \n" ; 

while  (true)  { 

sec_login__get_eag>iration  ( 
theServer->login_context , 

(long  int  *)  £expiration, 

^status) ; 

dce_error (status,  "Unable  to  get  context  expiration"); 
gettimeofday (£now,  NULL); 

sleep^time . tv^sec  «  expiration  -  now.tv__sec  -  600; 
sleep_tiiDe .  ty_nsec  =  0; 
if  (sleep^time. tv_sec  <  0)  { 

cerr  «  "Login  context  e^ires  too  soon"  «  endl;  exit(O); 

) 

pthread_delay_i^(£sleep_tiine)  ; 

^^®sh_identity  ( theServer->login__context ,  istatus)  ; 
dce__error (status,  "Unable  to  refresh  identity"); 
theServer->valid__and_cert  identity  ()  ; 

} 

} 


/ /  set  up  signal  handling  for  the  application  depend  on  long-lived  or  not 

pthread_addr_t  signal^catcher  (pthread_addr__t  arg)  { 
sigset^t  mask;  “ 

unsigned32  status; 

if  (DEBUG)  cout  «  "start  to  seti^  signal  handler.  ..  \n" ; 

sigenoptyset  (£niask)  ; 
sigaddset(£mask,  SIGTERM); 
sigaddset(£inask,  SIGINT); 
sigaddset(£mask,  SIGHUP)  ; 

sigwait(£inask)  ; 
if  (DEBUG) 

cerr  «  "signal  catched  and  I  am  going  to  stop  the  server.  . .  \n" ; 

rpc_mgmt_stop_server_listening(NULL,  4status)  ; 
dce__error (status ,  "Unable  to  stop  server  listening")  ; 


//  general  helper  fxmction 
//  create_thread()  : 

//  FUNCTIONALITY: 

//  create  thread 

// 

void  create_thread(pthread_startroutine_t  thread_routine , 
char  *thread_name, 
pthread_t  *thread_id, 
pthrea<^addr_^t  thread__arg)  ( 
unsigned32  status; 

status  «  pthread_create(thread_id,  pthread_attr_default, 
thread_routine,  thread_arg) ; 
if  (status  !-  0)  { 

cerr  «  "Unable  to  create  "  «  thread^name  «  "  thread\n"  ; 
exit (0) ; 

> 

pthread_yield() ;  /*  Allow  thread  to  run  now  */ 
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//  lcill_thread 
//  FUNCTIOHALITY: 

//  kill  thread 

// 

void  3cill_thread( 

pthread_t  thread_id, 
char  *  threac^name)  { 
xmsigned32  status; 
status  =  pthread_cancel  (thread  id)  ; 
if  (status  ?=  0)  { 

cerr  «  "Unable  to  kill  ”  «  thread_name  «  ”  thread\n”  ; 


//  is^server  there 
//  FUNCTIONALITy: 

//  Is  server  alive 

// 

boolean32  is_server_there  ( 

rpcjbinding_handle_t  h, 
rpc_if_handle_t  ifspec)  { 
boolean32  listening; 
\insigned32  status; 


listening  =  rpc_ingiat_is_server_listening(h,  ^status)  ; 
if  (status  =  rpc_s_binding_incoiiplete)  { 

^c_^_resolve_binding(h,  ifspec,  ^status)  ; 
if  ( (status  =  ept_s_jiot_registered)  |  | 

(status  =  rpc^s^conm^failure)  |  | 

(status  =  rpc_s_connect  rejected) ) 
return  (false)  ; 

(status ,  "Unable  to  resolve  binding"); 

^  listening  — >  rpe_ingmt_is_8erver_listening(h,  tstatus) ; 

if  ( (status  j=  rpc__s__coinn^failure)  |  | 

(status  =  rpc_s_connect__rejected) ) 
return (false) ; 

dce_error( status, "Unable  to  check  if  server  is  listening")  • 
return  (listening) ;  ^ 


/ /  dce__errro  () 

//  FUNCTIONALITy; 

//  Is  DCE  server  listening  for  incoming  calls 


void  dTO_error(unsigned32  status,  char  *ernnsg,  boolean32 
unsigned  char  errstr  [dce_c_error  string  len]  ; 
int  error  status;  “ 


aborl 


{ 


if  (status  error_status_ok)  { 

dee  error_inq[_text (status,  errstr,  terror  status); 
if  (error  status  error  status  ok)  { 
cerr  «  errstr  «  endl;  ” 

)  else  { 

endl-  "Could  not  get  error  text  for  status  "  «  statxis  « 

} 

if  (abort)  exit(O)  ; 

> 

) 
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//  DCE^client  dlflnitlon 
//  DCE^client:  :DCE^client  () 

//  FUNCTIONNALITY: 

//  get  binding  handle 

It  do  DCE  login  using  client  principal  identified 
//  setup  authentication  infonnation 
// 

DCE^^client : :  DCE^client  ( 

2:pc__if_handle_t  ih, 
unsigned_char_j>_t  srv_prin, 
unsigned_char_p_t  path, 
unsigned32  pt, 
unsigned32  authn, 
unsigned32  authz, 
unsigned_char_t  *  clnt_j>rin, 
unsigned_char_t  *  clnt_kt, 

Src^binding  sb, 
int  exp) 

•  if_handle{ih)  ,  server_principal  ( srvj>rin)  ,  binding_path(path)  , 
protection^level  (pt)  ,  authentication  (authn)  , 

authorization(authz)  ,  caient^principal  (clnt_j>rdLn)  ,  keytab^file  (clnt_kt)  , 
src^binding  (sb)  ,  ejg>iration  (e3q>)  ” 

{ 

get_binding_handle()  ; 
sec^loginO  ; 
setup_auth_info  0  ; 

} 


/ /  DCE_client : :  get_jDinding__handle  ( ) 

//  FUNCTIONALITY: 

//  check  source  of  the  binding 

/ /  translate  from  string  binding  to  normal  binding  when  the  source  is 
/ /  string  binding  get  binding  from  name  space  if  the  secirch  entry  is 
//  provided 
// 

void  DCE_client;  :get_binding__handle()  { 
rpc_ns_handle_t  import^context; 
if  (src^binding  =*  str)  { 

rpcJbindingr_from_s  tringjbinding  (binding[_path , 

£binding_handle , 

^status) ; 

dce_error (status,  "Unable  to  get  binding  handle  from  string 
binding”)  ; 

}  else  if  (src^binding  =  ns)  { 
rpc_ns_binding_iinport_begin  ( 
rpc_c_ns_syntax_def aul  t , 
binding_path , 
if^handle, 

NULL,  //  for  object  UUID 
fiiapor  t_context , 

£status) ; 

dce_error (status,  "Unable  to  create  an  inport  context  in  CDS  db")  ; 
rpc_ns_binding_ijnpor  t_jiext  (inport^^context ,  xi 
£binding_handle , 

^status) ; 

if  (status  rpc_s_no_more_bindings)  { 

cerr  «  "No  server  bindings  available\n" ; 
exit(O)  ; 

> 
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dce_©3rrojr ( status ,  "Unable  to  xinport  next  binding*  from  server",  0) 
rpc_ns_binding_iinpor t_done  ( tlji5>or t_context ,  &  s  tatus )  ; 

(status ,  "Unable  to  complete  binding  Import  from 

server")  ; 

) 

) 


/  /  DCE_client : :  get_binding  ( ) 

//  FUNCTIOKALITY: 

//  return  server  biding  handle  for  next  remote  call 

// 

^TC!^bindingr__handle_t  £  DCE^client;  zget  binding  ()  const  { 
return  binding  handle;  ” 

} 


//  DCE_client:  :sec_login() 

//  FUNCTIONALITT: 

//  wrapper  for  setup  identity 

// 

void  DCE_client:  :sec_login()  { 
setup__identity()  ; 

) 


/  /  DCE_client : :  settp^identity  ( ) 

//  FUNCTIOHALITY: 

//  setvp  client  principal 
/ /  validate  and  certify  client  principal 

//Or  get  client  principal  from  current  login  context  if  client 
/ /  principal  is  not  specified 

// 

void  DCE^client:  :set\p_identity  0  { 
if  (client_j>rincipal)  { 

sec_login_setup_identity  ( 
client_j>rincipal , 
sec_login__no_f lags , 

£login_context , 

£s tatus) ; 

dce_error (status,  "Unable  to  setip  identity  for  client 
principal")  ; 

valid_and_certjLdentity  0  ; 

dce_error (status,  "Unable  to  validate  and  certify  client 
principal")  ; 

)  else  { 

sec_login_get_current_context(4login_context,  £s tatus)  ; 

dce_error  (status ,  "Unable  to  get  login  context  from  the  inherited 
principal")  ; 

> 

} 


//  DCE_client:  :valid_and_cert  identity  () 

//  FUNCTIONAL! TT: 

//  get  client  principal's  key 
/ /  validate  identity 
//  free  the  key 

//  certify  the  client's  identity 

// 

void  DCE_client:  :valid_and_cert_identity  0  { 
void  ♦  key_data; 
sec__^login_auth_src_t  authn__src; 
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boolean32  reset^pas sword; 

sec_key_nignit_get_3c€y  ( 

rpc_c_authn_^dce_secret , 

(iinsigned_char_p_t)  keytab_file, 

(vinsigned_char_j>_t)  clientjprincipal , 

0,  //  latest  version 
&key_clata, 

£status)  ; 

deeper ror (status,  "Unable  to  locate  server  key") ; 

sec_login_validate_identity  ( 
login_context , 

( sec_j>as  swd_rec_t  * )  key_data , 

£reset_pas  sword, 

£autbn_src , 

^status) ; 

dee^^error (status,  "Unable  to  validate  identity"); 

sec_key_ingmt_free_key  (key_data,  ^status)  ; 

dce_error (status,  "Unable  to  free  server  k^")  ; 

sec_login_certi^_identity  ( 
login_context , 

(status) ; 

dee^error (status,  "Unable  to  certi^  identity  for  server")  ; 


//  DCE_client : :  sett5>_auth_info  () 

//  FUNCTIONALITY: 

//  annotate  the  security  on  the  binding  in  order  to  authenticate  with 
the  server 
// 

void  DCE_c3ient:  rseti^^auth^info  ()  ( 
rpc_binding_set_auth_inf  o  ( 
bindi ng_handle , 

(unsigned__char _p_t)  server^principal , 
protection_level , 
authentication, 

( rpc_auth_identi ty_handle_t)  login_context , 
authoriz  ation , 

(status)  ; 

deeper ror (status,  "Unable  to  seti:^  client  auth  info")  ; 

) 


//  DCE_client:  :^DCE_client  0 
//  FUNCTIONALITY: 

//  purge  login  context  and  free  acquired  resoiirces 

// 

DCE^client : :  ^DCE_client  ( )  { 

8ec_login_purge_context((login_context,  (status)  ; 
dee^^error (status ,  "Unable  to  purge  client  login  context",  0)  ; 

free  ( clientjprincipal)  ; 
free(server_principal)  ; 
f ree  (binding_path)  ; 

) 


myapp.h 

#ifndef  KYAPP  H 
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♦define  _HXAPP_H_ 

/  /  MODULE :  ny  app .  h 

// 

//  DESCailPTION: 

//  This  module  contains  declaration  of  class  DCE_server,  DCE  client  and 
//  some  helper  functions  of  these  two  classes  like  dce_error7 
is_8erver_there , 

//  create_thread,  kill_thread,  refresh_identity,  k^_mgmt, 
signal  catcher 
// 


//  INCLUDE  FILES 
#±nclude  <iostreaiiL.h> 
extern  "C"  { 

#±nclude  <stdio.h> 
#±nclude  <stdlib.h> 
#include  <tiine.h> 

#±ncliide  <dce/nbase .  h> 
#±nclude  <dce/dce_error .  h> 
#lnclude  <t>thread.h> 
#include  <dce/sec_login.h> 
#include  <dce/]ceyingiat.h> 
#±nclude  <dce/rpc.h> 
#include  '<^thread.h> 

) 


//  HELPER  FUNCTION  DECLARATIONS 
/*  dce_error: 

status  -  DCE  routine  status 

errmsg  -  descriptive  information  about  the  DCE  routine  that 
returned  the  status 

^ort  -  depend  on  critical  of  the  error,  exit  system  or  continue, 
default  is  exit  system 
*/ 

void  dce^error (unsigned32  status,  char  *errmsg,  boolean32  abort^l)  ; 

/*  is_server_there: 

h  *  binding  handle 

if spec  -  interface  specification 


PURPOSE;  Given  a  binding  handle  and  interface  specification,  test  if 
the  server  is  listening 
*/ 

boolean32  is_server_there(rpcJbinddLng_handle_t  h,  rpc  if  handle  t 
ifspec)  ;  —  ^  _ 

/*  create_thread()  : 

■thread_routine  -  the  main  boc^  of  the  routine  that  the  thread  will 
execute 

threac^name  -  assign  a  name  to  this  thread 

thread_id  -  the  ID  return  by  the  system  to  identity  the  thread 
thread_arg  -  extra  information  that  can  pass  the  thread  when 

executed 


PURPOSE:  Helper  function  to  create  a  create,  given  a  function  to 
execute 

*/ 

void  create_thread( 

pthread_startroutine_t  thread_routine , 
char  *thread_name, 
pthread_t  *thread_id, 
pthread_addr_t  thread_arg) ; 
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/*  kill^thread: 

thread_±d  -  thread  ID  got  when  create  the  thread 
thread_^nanie  -  the  name  assigned  to  thread  when  the  thread  is 

created 

PURPOSE:  Helper  function  to  kill  a  thread,  given  a  thread  ID  and 
thread  name 
*/ 

void  kill_thread  (pthread_t  thread_id,  char  *  thread_naine)  ; 

/*  refresh_identity  0  : 

arg  -  expect  a  (DCE__server  *)  arg 

PURPOSE:  Helper  thread  to  refresh  DCE  credentials  in  predefined 

*/ 

pthread_addr_t  ref resh_identity  (pthread_addr_t  arg)  ; 

/*  k^_mgmt  0  : 

arg  -  e3g>ect  a  (DCE_server  *)  arg 

PURPOSE:  Helper  thread  to  manage  the  server  key 

pthread_addr_t  k€y_mgmt  (pthread_addr_t  arg)  ; 

/*  signal^catcher  0  : 
arg-  not  used 

PURPOSE:  Helper  function  to  setup  signals  and  wait  for  any  of  these 
signals  happen 
*/ 

pthread_^addr_t  signal^catcher  (pthread_addr_t  arg)  ; 

/*  class  DCE^server: 

PURPOSE:  enc^sulate  the  functionality  of  setting  vtp  a  DCE  server 
most  of  the  default  parameters  are  provided,  users  can 
leave  it  as  it  is  and  create  the  class  or  he/ she  can  change 
the  parameters  to  the  value  he/she  want. 

PREREQUISITE:  (required  only  when  the  server  will  eaq>ort  to  T>aing> 
space) 

ENVIRONMENT  VARIABLE :  this  version  requires  you  to  set  up  the 
following 

environment  variables  before  running  the  server.  You  can  write 
a  script  to  set\q>  these  environment  variable  and  then  invoke  the 
server 

SERVER^ENTRY :  entry  name  of  CDS  to  e3q>ort 

GROUP_ENTRY  (optional)  :  groTq>  entry  of  CDS  that  will  contain  the 
server  entry 

PROFILE_ENTRY  (optional)  :  profile  entry  of  CDS  that  will  contain  the 
groiq>  entry 

CONSTRUCTOR  PARAMETERS: 
xh  -  interface  handle  (mandatory) 
prin  -  server  principal  nazoe  (mandatory) 

mgr^type^uuid  -  default  to  NULL  (  not  used  in  this  version  ) 
mgi^epv  —  default  to  NULL  (  not  used  in  this  version  ) 
p  -  protococol  used,  default  to  "all",  the  others  are  "u<to"  or 

"tep" 

authn_lg  -  authentication  login  (default  is  no) 
protection  -  protection  level,  default  is  ” rpc_c_pr otectJLevel__none 
possible  values  are: 
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(no  authentication) 

^9_®-P^®^®^'t_l®'v®l_default (same  as  rpc^j>rotect__pkt^integ) 
*Tc_c_j>rotect_level__connect  (authenticate  when  client  connect) 

(authenticate  at  each  remote  call) 
tec t_levelj*t (authenticate  at  each  packet  received) 
5TCLC_j)rotect_level_j>kt_integ  (ensure  none  of  the  data  have  been 

modified) 

^9_9-J>^®tect_level_j>kt_privacy  (enscription  plus  previous) 
authn  -  authenication  service,  default  to  "rpc_c_authn  none" 
possible  values  are;  ~ 

^^thn_none  (no  authentication) 

^9-CLa^thn_dce_secret  (DCE  share-secret  key  authentication 
9-.^'^thn^default (the  same  as  rpc_c__authn_dce  secret) 

^9— 9— *^thn_^dce jpublic  (reserved  for  future  release) 
authz  -  authorization  service,  default  to  ”rpc_c  authz  none” 
possible  values  are : 

ipc__c_authz_none  (no  authorization) 

rpc_9_authz_name  (authorization  based  on  client  principal) 

^9— (perform  authorization  using  client '  s  PAC) 

“  keytab  file  path  (mandatory) 
ep  -  e3q>ort  to  enc^oint  (default  yes) 

ns  -  e3Q)ort  to  namespace  (default  yes) 

■  does  server  start  listening  immediately  (default  to  yes) 

PUBLIC  MEMBER  FUNCTIONS: 

listen  0  -  allow  server  to  do  customization  before  actually 

Ixsten  for  incoming  calls 
*/ 

class  DCE^server  { 

friend  pthread_addr_t  refresh_identity  (pthread_addr  t  arg)  ; 
friend  pthread_^addr_t  key_mgmt  (p thread  addr  t  arg)  ; 
public :  ""  “ 

//  type  declarations  first 
enum  l^roto  {all,  uc^,  tcp)  ; 

DCE__server  ( 

rpc_if_handle_t  ih, 
unsigned_char_t  *  prin, 
nuid_t  *mgr_type_uuid==NUIiL, 
xpc_mgr_^y_t  mgr__epv=NUIiL, 

Myproto  p=  all, 
int  authn_lgn  =  0, 

unsigned32  pro  tection=2:pc_c_protec  t_level_none , 

unsigned32  authn  =  rpc_c_authn_none , 

unsigned32  authz  =  rpc_c_authz_none , 

unsigned_char_p_t  kt  =  NULL, 

int  ep  =  1, 

int  ns  *=  1, 

int  is_listen  =  1 

); 


^DCE_^server  0  ; 
void  listen  0  ; 
private: 

/ /  methods  second 

void  register_interface() ;  void  iisejprotocol () ;  void 

;  void  sec_login()  ;  void  seti^)  identity  ()  ; 
void  register_en(^oint()  ;  void  e3g)ort_to  namespace  ()  ;  void 
start_iiigin.t_thread()  ;  void  start_signal_thread()  ; 
void  valid_and_cert_identity  () ; 

//  attributes  last 

J5>9_if_l»ai»dle_t  if_handle;  uuid_t  *ingr  type  uuid  of  obj; 
rpc_ingr_epv_t  iiianager_epv;  ~  ~  ~ 
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Myproto  Hereto;  uns±gned32  protection_level ;  unsigned32 
authentication;  unsigned32  authorization; 

unsigned_char_t  *  principal;  unsigned_char__t  *  key tab_f ile ; 
rpc_binding__vector_t  *  bv;  sec_login_handle_t 

login_context;  int  authn^login;  int  en(^oint;  int  name__space; 
rpc_if_id_t  if_id;  unsigned_char_t  *  server^entry; 

unsigned_char_t  *  group_entry;  unsigned^char^t  *  profile_entry; 
pthread^t  refresh_id__thread;  pthread^t 

k^_ingmt_thread;  pthread_t  sigcatch_thread;  unsigned32  status; 

>; 


/*  class  DCE_client 

PX7BP0SE:  enc^sulate  the  action  of  set  vqp  server 
CONSTRUCTOR  PARAMETERS: 

ih  -  interface  handle  of  the  interface  that  a  specific  server 
st^ort 

sry_j)rin  -  the  server  principal  name 

path  -  a  string  binding  or  a  NSI  entry  in  CDS  to  locate  the 

server 

pt  -  protection  level,  default  is  " rpc__cj>rotect_level_none 
possible  values  are: 

rpc_c_protect_level_none  (no  authentication) 
ipc_cjprotect_level_default (same  as  rpc_j>rotect_j>kt_integ) 
rpc_^c_protect_level_connect  (authenticate  when  client 

connect) 

rpc^c ^rotect^level_call  (authenticate  at  each  remote  call) 
rpc_c_protect_level_pkt  (authenticate  at  each  packet 

received) 

rpc_c_j>rotect__level_fJct_in  teg  (ensure  none  of  the  data  have 
been  modified) 

rpc_c_protect_level__pkt_j)rivacy  (enscription  plus  previous) 
authn  -  authenication  service,  default  to  "rpc_c_authn_none” 
possible  values  are: 

rpc_c_authn_none  (no  authentication) 

rpc_c_authn^dce_secret  (DCE  share- secret  key  authentication 
rpc_^c^authn_^default  (the  same  as  rpc^c_authn  dee  secret) 
rpc_c_authn_dce_j)ublic  (reserved  for  future  release) 
authz  -  authorization  service,  default  to  "rpc__c_authz_none" 
possible  values  are: 

rpc_c_authz_none  (no  authorization) 

rpc_c_authz_name  (authorization  based  on  client  principal) 
rpc_c_authz_dce (perform  authorization  using  client's  PAG) 
clnt_prin  -  client  principal  name 

clnt_kt  -  client  keytab  file 
sb  -  source  of  binding  handle 
possible  values  are: 

DC£_client:  :ns  (inport  the  binding  from  nairna  space) 
DCE_client: :  str  (the  source  is  string  binding) 
es^  -  if  the  CDS  cache  data  is  out  of  data,  then  force  high 
confidence 

(not  inplemented  yet,  so  put  in  the  default  value) 

PUBLIC  METHODS: 

xpc_binding_handle_t  &  get_binding()  const: 

return  a  binding  handle  in  order  for  client  to  call  the  remote 
methods  siipported  by  the  remote  server 

*/ 

class  DCE^client  { 
public: 

//  type  declarations  first 
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enina  Srcjbinding  {ns,  str} ; 

DCE_clxent  ( 

rpc_ifjhandle_t  ih, 
unsigned^cliax^'t  *  svr__prin , 
iinsigned_char_t  *  path, 

'unsi.gned32  pt  *  ipc_cjprotect^level  none, 

Tins±gne<i32  authn  =  rpc^c^authn  none, 
tins±gneci32  anthz  *  rpc^c_auth2  none, 
iinsigned_char_t  *  cant_j>rin=NUlii , 
unsigned_char_t  *  clnt^kt  =  KULL, 

Src_binding  sb=DCE_client : : ns , 
int  exp  =  0)  ; 

^DCE^client  ()  ; 

rpc_binding_haiidle_t  &  getJbindingO  const; 
private : 

//  methods  second 

void  getjDinding_handle() ;  void  sec_login()  ;  void 
seti^_identity  0  ;  void  valid_and_cert_identity  ()  ;  void  set\;p_auth_inf o  ()  ; 
//  attributes  last  ““ 

rpc_if_handle_t  if^handle; 
unsigned^char^t  *  binding_j>ath; 

Srcjbinding  srcjbinding; 
rpCjbinding[jhandlejt  binding  handle; 
unsignedjChaTjt  *  client^rincipal ; 
unsignedjCharjt  *  server_jprincipal ; 
unsigned32  protectionjlevel; 
unsigned32  authentication; 
unsigned32  authorization; 
int  expiration; 

sec  jloginjhandle  jt  login  jCon text ; 
unsignedjChaTjt  *  keytabjfile; 
unsigned32  status; 


#endif 


aiarm_a.c 

T* 

FIhE :  alam^a .  c 
DESCRIPTION: 

file  contains  the  iioplementation  of  a  al  a-rrri  agent  server  that 
accepts  registration  from  client.  After  a  client  registers,  the  server 
save  the  client's  binding  information  in  a  list  structure.  The 
server  can  inform  all  the  clients  in  the  list  when  it  receives  some  alert 
using  secure  DCE  RPC. 

*/ 

//  INCLUDE  FILES 

#include  "myapp.h" 
extern  "C”  { 

#include  ”alarm_a.h" 

#include  "alaxm_c.h” 

) 

#def  ine  DEBUG  0 

//  list  node  structure  to  hold  binding  information 
struct  Clientjt  { 
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rpc_biiiding_liandle_^t  h; 
struct  Client^t  *  next; 

>; 

Client__t  *  cl±ent_Jheader  «  NULL; 

//  void  noti^_client()  : 

//  FUNCTIONALITY: 

//  foreach  client  on  the  list,  retrieve  the  binding  handle 
//  annotate  the  security  dlnfonnation  on  the  binding  handle 
//  call  the  notify  interface  that  the  client  supports 

void  noti^^client  {)  { 

Client^t  *p  =  client_header; 
error_status_t  status; 

while (p)  { 

rpc_binding_set_auth_inf  o  ( 
p->h, 

(unsigned_charjp_t)  ”alarm_agent" , 
rpc^c^rotect__level_^def  ault , 
rpc_c_authn_def  ault , 

NULL, 

rpc_c__authz__naine , 

(status 

); 


if  (status  !=  rpc_s_ok)  { 
switch  (status)  { 

case  rpc_s_invalid_binding: 

cout  «  ”rpc_s__invalid_binding\n” ; 
break; 

case  rpc_sjwrong__kind_ofJbinding: 

cout  «  "rpc__s_wrong_kind__of_binding\n" ; 
break; 

case  rpc__s_unknown^authn__service : 

cout  «  "rpc_s_unknow_authn_service\n*' ; 
break; 

case  rpc_^s_^authn_authz_^siDatch: 

cout  «  ”  rpc_s_authn_authz_inisinatch\n"  ; 
break; 

case  rpc_s_junsi5)ported_j>rotect_level : 

cout  «  ”rpc_s_uns’i5>portedj>rotect_level\n" ; 
break; 

default: 

cout  «  "unknown  error\n”; 

) 

cerr  «  "alazmClient  set  auth  info  failed"; 
exit(O)  ; 

) 

dce_^error (status,  "Unable  seti^  security  with  sndlandle  of 
alam^c") ; 

noti^  (p->h)  ; 

ps=p-Miext; 

> 

} 
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//  void  insertClientlaf o  (client^t  *  pClient) 
//  FUNCTIOHALITY; 

/ /  insert  the  client  into  internal  list 
void  insertClientInf o  (Client_t  *  pClient)  { 
Client_t  *t; 

Client_t  *p  =  pClient; 
if  (client_header)  { 
t=client_header ; 

while  (t“>next)  { 
t  «  t“>next; 

} 

t->next^; 
p  ->  next  =  NULL; 

}  else  { 

client_header=^lient; 
client_header“>next  =  NULL; 

} 

} 


//  client_reg{) 

//  FUNCTIONAL! Tf: 

//  the  ing)l€mentation  of  the  alarm  agent  interface  that  allows  client 
//  to  register  and  the  server  can  convert  the  binding  and  save  the 
//  binding  into  a  list 

void  client_reg (handle  t  h,  error  status  t  *st) 

error_status_t  status; 
rpc_binding_handle^t  SvrHandle; 

Client_t  *  pClient; 

rpc_binding_server_from_client(h^  t SvrHandle,  ^status)  ; 
if  (status  !=  rpc_s_ok)  { 

cerr  «  "can  not  convert  client  handle  to  server  handle\n"  ; 

♦st  »  -1; 
return; 

> 

cout  «  "successfully  converted  client  binding  to  server  binding 
handle\n" ; 

pClient  =  (Client_t  *)  malloc  ( si zeof  (Client  t) ) ; 
pClient- >h  =  SvrHandle; 
insertClientInf o  (pClient)  ; 

cout  «  "alarmClient  registered  successfully\n"; 

*st=error_status  ok; 

//  pthread_addr_t  driver  () 

//  FUNCTIONALITY: 

//  a  thread  that  will  call  client '  s  noti^  function  when  a  key  is 
pressed 

pthread_addr_t  driver  (pthread_addr_t  arg) 
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{ 

while  (1)  ( 

printf  ("Press  any  key  to  send  notification  to  cllents\n")  ; 
getcharO  ; 
notl^^cllent  ()  ; 

prlntf  ("Press  another  key  to  go  to  next  ronndXn")  ; 
getcharO  ; 

> 

) 


//  malnO 
//  FUNCTIONALITf: 

//  create  a  alazm^agent 

//  seti^  a  driver  thread  to  call  alarm  client  *s  notl^  function 
//  listen  for  the  Incoming  calls 
Int  malnO  { 

pthread_t  drlver_ld_thread; 

DCE^server  alaxm_agent( 

alani^agent_lf_vl__0_s__lf  spec , 

(unslgned_char_t  ♦)  "alarm_agent"  ,  //  using  know  existing 
principal 

NUUi, 

NULL, 

DCE_server:  :vidp, 

1/ 

J^pc_c_protect^level_j>kt^lnteg, 
rpc_c_^authn^dce_secret , 
rpc_c_^authz_name , 

(xmslgned_char_t  *)  "/audlt/keytabs/alam^agent"  , 

1, 

1/ 

0)  ; 

create_thread (driver ,  "driver  thread"  ,4drlver_id_thread,  NULL)  ; 

cout  «  "alazm_agent  Is  listening.  ..  \n"  ; 

alarm_agent. listen  0  ; 
return  0; 

) 


aJar!nnL.a.h 

/*  Generated  by  OSF  DCE  IDL  conpUer  */ 
#lfndef  alarm_agent_lf_vl_0_lncluded 

#deflne  alani^agent_lf_vl_0_lncltided 

#lfndef  _ STDC 

#deflne  volatile 

#lfndef  IDLBASE_H 
#lnclude  <dce/ldlbase.h> 

#endlf 

#lnclude  <dce/rpc.h> 

#lfdef  cplusplus 
extern  "C"  { 
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#eiidif 


#lfndef  nbase_vO_0_included 
#±nclude  <dce/nbase .  h> 

#eiidif 

extern  void  caient_reg( 

#ifdef  IDLJPROTOTYPES 
/*  [in]  */  handiest  binding, 

/*  [out]  */  error_status_t  ^status 
#endif 


); 


typedef  struct  alana_agent_if_yl__0_epv_t  { 
void  (*  alien t_reg)  ( 

#ifdef  IDL_PROTOTYPES 
/*  [in]  */  handle__t  binding, 

/*  [out]  */  error_status__t  *  status 
#endif 


)  ; 

>  alarm_agent_if_vl_0_epy_t; 

extern  rpc_if_handle_t  alarni_agent_if_vl_0__c_ifspec; 
extern  rpc_if_handle_t  alarm__agent_if_vl_0_s_ifspec; 

#ifdef  cplusplus 

} 

#endif 

#endif 


afarmjajdl 

/*  alarm_a.idl  file  */ 

[  uuid(000493e0-b8b9-1444-8360-00a0246561aa)  ,  version(l.O)  ] 

interface  alarm_agent_if 

{ 

void  client_reg  ( 

[in]  handiest  binding, 

[out]  error_status__t  *  status 

> 


aJamTMC.c 

. 7* 

FILE :  alami_c .  c 
DESCRIPTION: 

The  file  contains  implementation  of  a  alarm  client  that  is  itself 
also  a  server.  Bie  alarm  client  implements  a  call  back  function  for  a 
alarm  server  to  call  when  there  are  important  events  happen.  The  client 
itself  need  to  call  the  alarm  server  client_reg  function  in  order  for  the 
server  to  locate  the  client  to  inform  these  special  events . 

*/ 
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//  INCLUDE  FILES 
#±nclude  "iny«5)p.h” 
extern  "C  { 

#lnclude  ”alanii_c.h" 

#include  "alaxm^a.h” 

) 

//  noti^O 

//  FUNCTIONALITY 

//  the  inplementation  of  the  function  that  the  alarm  agent  can  all  to 
noti^ 

//  alarm  client 

void  notify  (handiest  h) 

{ 

cout  «  "emergency  announcement  from  server\n” ; 

} 

//  mainO 
//  FUNCTIONS 

//  create  c_alarm_^client  to  sett^  relationship  with  alert  agent 
//  create  alarm_client  that  is  actually  a  DCE  server  that  exports 
//  the  notij^  functionality  get  the  binding  from  the  c_alarm_client 
//  that  contains  the  binding  to  alarm  agent  registered  with  the  a1  arm 
//  agent  listen  for  the  call  back  from  the  server 
int  main  (int  argc,  char  *argv[])  { 

//  setip  as  server  first  to  make  sure 
imsigned32  status; 

DCE^client  c^al  arm^client  ( 

alarm_agent_if_vl_0_c_if  spec , 

(unsigned_char_t  *)  "alarm_^client"  ,  //  using  the  client  principal 

name 

(unsigned_char_t  *)  ”  / . : /audit/alarmjaetl_profile”  ,  //  Namespace 

search  starting  point 

rpc__c_pro  tect_level_pkt_integ , 
rpc_c_authn_dce_secret , 
rpc__c_auth2_name , 

(unsigned_char_t  *)  ”  alarm_client" ,  //  using  the  client  principal 

name 

(unsigned__char__t  *)  "/audit/key tabs/a  1  am^client"  ,  It  client 

keytab 

DCE^client : :  ns 

); 


DCE_serv€u:  alarm^client  ( 

alarn^client_if_vl_0_s_if  spec , 

(unsigned^char^t  *)  "alarm^client”  ,  //  using  the  client  principal 

name 

NULL, 

NULL, 

DCE^server : :  u<^ , 

1, 

rpc_c_protect__level_def  ault , 
rpc_c_authn_def  ault , 
rpc_c_auth2_jiame , 

(unsigned_char_t  *)  "/audit/keytabs/alam^client" ,  //  client 

keytab 

0,  //  there  is  no  need  to  export  to  name  space  for  alarm^^client 

0  //  also  do  not  listen  until  the  client  is  seti^ 

)  ; 
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} 


const  rpo_blnding_handle_t  th  =  c_alarm_olient.get_binding() ; 
client_reg{h,  ^status) ; 

"Unable  to  register  alam^client  interface\n")  ; 

alana_client.listen() ; 
return  0; 


alarrnjc.h 

/*  Generated  by  OSF  DCE  IDL  conpiler  */ 
#ifndef  alana_client_if_vl_0_included 
#define  alarm_client_if_vl_0_inclnded 

#ifndef  _ STDC _ 

#deflne  volatile 
#endif 

#include  <dce/idlbase .  h> 

#endif 

#±nclude  <dce/rpc.h> 

#ifdef  cplusplus 
extern  "C"  { 

#endif 

#ifndef  nbase_y0__0_inclnded 
#include  <dce/nbase .  h> 

#endif 

extern  void  noti^( 

#ifdef  IDL_PBDTOTYPES 

/*  [in]  */  handle  t  bindina 
#endif 


); 

iTj^pedef  struct  alarni_client_if_vl_0  epv  t  { 
void  (*notify) (  ” 

#ifdef  IDL^PRDTOTTPES 

/*  [in]  */  handle  t  binding 
#endif 

); 

)  alam^client^if  vl  0  epv  t; 

extern  rpc^if_handle^t  al  ann_client^if^vl_0_c  if  spec; 
extern  rpc_if^handle_t  alana_^client_^if^vl^O  s  if  spec; 

#ifdef  cplusplus 

} 

#endif 

#endif 


aJamjjc.jdl 

/♦  alarm^c.idl  */ 
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[  uald(0070ea40-b8bl-1444-8360-00a0246561aa) ,  verslon(l.O)  ] 


interface  al  anii_client_if 

[maybe]  void  notify  ( 

[in]  bandle_t  binding 

)  ; 

} 
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Glossary 

/...  -  The  DCE  root  directory.  Every  DCE  object  can  be  addressed  under  this  directory. 
Immediately  under  this  directory,  you  would  expect  to  see  the  names  of  DCE  cells.  This 
effectively  makes  every  DCE  cell  "connectable"  to  every  other  DCE  cell  in  the  world  since  /... 
is  a  global  root  directory. 

/.:  -  A  shortcut  that  refers  to  the  CDS  path  /.../cell_name  (where  cell_name  is  the  name  of  the 
local  cell).  This  is  used  to  refer  to  the  local  cell. 

/:  -  A  shortcut  that  refers  to  the  CDS  path  /.../cell_name/fs  (where  cell_name  is  the  name  of  the 
local  cell).  This  is  used  to  refer  to  the  local  cell’s  DFS  namespace. 

Access  Control  Lists  or  ACLs  -  Based  on  POSIX  1003.6  ACL  Authorization,  DCE  ACLs  are 
maintained  by  a  resource  owner  in  order  to  protect  its  resources.  The  ACL  contains  a  list  of 
identities  that  may  be  authorized  to  access  the  resource  in  some  way,  and  a  set  of 
permissions  granted  to  each  identity.  This  is  similar  to  the  permission  bits  on  UNIX  files. 

ACL  key  -  The  name  of  the  identity  to  which  the  ACL  permissions  apply.  Some  ACL  types  do  not 
have  an  ACL  key. 

ACL  manager  -  Application  developers  may  chose  to  develop  an  ACL  manager  as  part  of  the 
server  process  that  they  design.  An  ACL  manager  enforces  the  ACL  security  mechanisms. 
It  compares  the  identity  of  the  client  making  a  request  with  the  entries  in  the  ACL  database 
protecting  that  resource,  and  either  grant  or  deny  the  request. 

ACL  permissions  -  A  set  of  characters  where  each  character  represents  a  particular  permission 
(to  the  object  that  the  ACL  protects).  For  example,  the  permission  character  "r"  may  grant 
"read"  permission  to  the  object  being  protected,  while  "c"  may  determine  that  a  principal  may 
change  the  ACL  itself. 

ACL  type  -  The  type  of  identity  specified  in  the  next  field  in  this  ACL  entry.  For  example,,  a  type 
might  be  "user",  indicating  that  the  next  field  in  the  ACL  is  the  name  of  a  user. 

Account  (or  login  account)  •  Information  related  to  a  user/system/server  application,  required  for 
DCE  login.  For  example,  a  user  called  "Neil"  may  have  a  login  account  in  the  DCE  Security 
Server  Registry  database  vrhich  holds  his  password,  home  directory  etc.  This  is  very  similar 
to  the  UNIX  /etc/passwd  file  in  form  and  contents. 

acl_edit  -  acl_edit  (the  ACL  editing  program)  is  a  DCE  version  1 .0  utility  that  displays  &  modifies 
ACLs  on  DCE  objects.  Much  of  the  functionality  of  acl_edit  has  been  migrated  to  the  newer 
"dcecp"  command  suite. 

Application  Code  -  The  core  logic  of  the  application. 

Authentication  -  Users  in  a  DCE  cell  are  considered  to  have  authenticated  once  they  are  logged 
in.  Authentication  is  essentially  proving  your  identity  to  the  DCE  Security  Server. 

Availability  -  A  high-availability  computing  solution  is  one  where  failure  of  no  single  component 
can  interrupt  operation. 

Binding  or  RPC  binding  handle  -  The  connection  information  shared  by  a  client  and  server.  This 
information  includes:  the  UUID  that  defines  the  interface  that  client  &  server  share,  .an 
address  of  the  server,  a  protocol  sequence  that  client  &  server  can  communicate  with,  the 
port  number  associated  with  the  server's  interface,  and  optionally  the  object  UUID  uniquely 
identifying  that  server  interface  instance,  (see  also  String  Binding) 
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CDS_Convergence  -  CDS  directories  and  objects  hold  data  in  the  form  "attribute  =  value".  For 
example,  the  CDS  directory  /.:/subsys  may  have  an  attribute  called  CDS_Convergence 
whose  value  may  be  "high,"  "medium,"  or  "low".  This  CDS_Covergence  value  (of  meduim) 
specifies  the  approximate  time  period  within  which  changes  to  a  master  will  be  propagated  to 
readonly  replicas  (copies)  of  that  directory. 

cdsadv  -  The  CDS  advertiser  program.  On  a  CDS  server  system,  cdsadv  periodically  sends  out  a 
UDP  broadcast  to  advertise  that  this  system  has  a  portion  of  the  CDS  database.  This  is  the 
one  method  through  which,  clients  learn  about  the  location  of  CDS  servers.  On  a  client 
system,  the  cdsadv  process  is  the  parent  process  for  each  cdsclerk  process. 

cdsclerk  -  cdsclerk  is  the  process  that  makes  client  requests  into  the  CDS  database.  When  used 
there  will  be  one  cdsclerk  process  per-userid  &  groupid  combination  on  a  DCE  system. 

cdscp  -  cdscp  (the  CDS  control  program)  is  a  DCE  version  1.0  utility  that  accesses  the  CDS 
database.  Much  of  the  functionality  of  cdscp  has  beed  migrated  into  the  newer  "dcecp" 
command  suite. 

cdsd  -  cdsd  is  the  name  of  the  Cell  Directory  Service  (CDS)  server  process.  This  process 
manages  the  clearinghouses  that  comprise  the  CDS  database. 

Cell  -  A  DCE  cell  is  a  collection  of  logically  related  DCE  computer  systems  that  share  a  common 
security  service  and  a  directory  service. 

Cell  Dire^ory  Service  Server  (CDS  server)  -  The  process  (cdsd)  that  maintains  a  database 
containing  addresses  of  other  DCE  processes.  Client  access  to  this  server  is  through  the 
CDS  advertiser  (cdsadv)  and  CDS  clerk  (cdsclerk)  processes. 

cell-profile  -  A  profile  entry  in  the  CDS  database.  It  is  a  special  entry  in  that  it  is  used  to  help  a 
client  locate  other  information  in  the  CDS  database  i.e.  it  is  part  of  the  "search  engine"  used 
internally  by  CDS.  The  cell-profile  may  contain  references  to  server  entries  (binding 
information)  for  server  processes  that  exist  ANYWHERE  in  a  cell. 

Child  pointer  -  The  pointer  that  links  a  parent  directory  to  its  children.  This  is  a  downward  linked 
list  from  parent  to  child  throughout  the  CDS  namespace.  In  this  way  navigation  can  span 
clearinghouses  and  replicas. 

Clearinghouse  -  A  physiwl  portion  of  the  CDS  namespace.  The  CDS  namespace  can  be  split 
across  several  clearinghouses  and  any  or  all  of  those  portions  can  be  replicated  in  other 
clearinghouses.  The  clearinghouse  is  just  an  instance  of  the  CDS  database. 

Client  -  A  DCE  client  is  the  process  that  requests  a  service  from  a  DCE  server  process.  The 
client  requests  this  service  by  means  of  a  Remote  Procedure  Call  (RPC)  and  the  server 
responds  to  the  RPC  in  accordance  to  the  interface  specification  for  that  RPC  binding. 

Clock  drift  or  Drift  -  The  local  time  on  a  computer  is  based  on  an  oscillator  in  the  computer’s 
hardware.  This  oscillator  is  not  perfect  and  therefore  the  system  time  drifts  either  ahead  or 
behind  true  UTC. 

Clock  skew  or  Skew  -  When  two  separate  systems  clock  values  drift  apart  with  respect  to  each 
other,  the  differerice  between  their  clock  values  is  defined  as  their  clock  skew.  Clock  skew  is 
computed  taking  into  account  network  propagation  delay  as  much  as  practicable. 

Compatible  binding  -  a  client  and  server  are  considered  compatible  if  their  interface  UUIDs  match 
and  their  version  numbers  are  similar. 

Complete  binding  -  see  String  Binding 
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Courier  Server  or  courier  -  A  courier  server  is  a  special  kind  of  DCE  local  time  server  that,  when  it 
synchronizes  (to  set  it's  own  local  clock)  always  takes  at  least  one  time  value  from  a  global 
server  (usually  located  in  a  different  location).  Then  the  courier  server  gives  it's  own  clock 
time  to  clients  in  it's  own  or  LAN  segment.  Hence,  by  taking  time  from  an  external  server  and 
providing  time  to  a  set  of  local  systems,  the  courier  ensures  that  the  global  server  influences 
the  time  values  held  by  clerks  (clients)  in  a  LAN. 

Credentials  -  Credentials  uniquely  define  your  DCE  identity.  Your  aedentials  include  your 
principal  name  as  well  as  the  groups  that  you  belong  to.  Credentials  are  stored  in  a 
Extended  Privilege  Attribute  Certificate  (EPAC)  and  are  issued  at  login  time. 

Dynamically  Linked  Libraries  or  DLLs  -  A  Dynamically  Linked  Library  is  a  file  that  resides  on  disk 
and  is  used  by  the  main  part  of  an  application  program  whenever  it  is  needed.  It  is  not 
permanently  joined  to  the  application  in  order  to  reduce  executable  size  etc  and  to  de-couple 
the  application  from  it's  library.  DLL  is  a  Windows  specific  term  though  the  same  concept 
applies  to  most  modem  operating  systems. 

dcecp  -  dcecp  (the  DCE  control  program)  is  a  DCE  version  1 .1  programmable  shell  (based  in  tcl 
version  7.3)  that  allows  an  administrator  to  manage  DCE  services.  This  control  program 
largely  replaces  the  older  control  programs  cdscp,  rpccp,  dtscp,  rgy.edit,  acl_edit,  and 
sec_admin. 

deed  -  deed  is  the  name  of  the  most  fundamental  DCE  process  that  runs  on  every  DCE  system. 
The  process  deed  performs  several  tasks  : 

1)  It  is  the  client  interface  to  the  security  service,  i.e.  it  helps  obtain  tickets  for  the  client  host, 
deed  is  the  process  that  logins  into  the  DCE  Security  Service  as  hosts/hostname/self. 

2)  It  performs  the  endpoint  mapping  task.  When  a  server  process  starts  up,  it  must  register 
the  endpoint  that  it  is  listening  for  requests  on  with  the  deed  endpoint  mapper  interface. 
Later,  when  a  client  looks  for  a  particular  interface,  deed  provide  the  endpoint. 

3)  It  perfonns  the  local  location  broker  task.  This  is  a  similar  "endpoint  mapping"  service  but 
for  an  older  technology  when  deed  still  supports. 

4)  It  performs  a  data  file  management  surrogate  role  that  enables  remote  administration. 

5)  It  performs  a  process  management  role  that  enables  remote  administration. 

Directory  Replica  -  A  physical  instance  of  a  CDS  directory  (within  a  particular  clearinghouse) 

Domain  Name  Service  or  DNS  -  The  domain  name  service  (DNS)  is  the  most  common  naming 
service  used  by  systems  on  the  internet.  DNS  helps  turn  a  logical  name  of  a  system  into  a 
physical  address.  The  domain  naming  service  (DNS)  may  be  used  by  DCE  in  order  for  a 
client  in  one  cell  to  locate  a  server  in  another  cell. 

Drift  •  see  Clock  Drift 

DTS  or  Distributed  Time  Service  -  This  is  time  service  that  DCE  uses  to  synchronize  the  local 
systems  clocks  throughout  a  DCE  cell.  Like  Network  Time  Protocol  (NTP),  DTS  ensures  that 
time  will  be  synchronized  without  ever  allowing  time  to  move  backward. 

dtscp  •  dtscp  (the  DTS  control  program)  is  a  DCE  version  1 .0  utility  that  accesses  time  service 
related  infonnation.  Much  of  the  functionality  of  dtscp  has  been  migrated  to  the  newer  "dcecp" 
command  suite. 

dtsd  -  dtsd  is  the  name  of  the  DCE  Time  Service  (DTS)  server  process  or  client  process.  Since 
the  same  binary  name  may  behave  as  either  a  server  or  a  client,  flags  are  normally  specified 
to  dtsd  at  startup  to  define  whether  to  behave  as  a  client  or  a  server. 

Dynamic  endpoint  -  Most  DCE  processes  do  not  use  a  fixed  endpoint  (one  that  never  changes). 
Most  DCE  processes  are  assigned  an  endpoint  number  (port  number)  when  they  start  up  - 
this  is  a  dynamic  endpoint  (since  it  may  change  every  time  the  process  starts  up).  This  gives 
rise  to  the  need  for  an  endpoint  mapper  function  supported  by  deed. 
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Encrypted  -  An  encrypted  message,  sent  from  one  computer  to  another,  is  a  message  where  all 
of  the  data  contained  in  the  message  is  scrambled  before  transmission.  Only  those  who 
know  the  secret  key  (password)  that  was  used  to  scramble  (encrypt)  the  message  may 
unscramble  (de-crypt)  the  message. 

Endpoint  or  Port  -  In  DCE,  the  terms  endpoint  and  port  are  synonymous.  An  endpoint  (or  port)  is 
a  refinement  of  a  network  address.  Since  many  processes  may  run  simultaneously  on  a 
system  with  an  IP  address,  endpoints  allow  connections  to  specific  processes.  Each  server 
process  "listens"  for  requests  on  one  or  more  endpoints.  Clients  then  dynamically  discover 
what  endpoints  the  server  is  listing  on  for  a  particular  interface,  and  then  contacts  the  server 
at  the  IP  address  and  endpoint  (e.g.  100.200.100.200(3456]). 

Extended  Privilege  Attribute  Certificate  or  EPAC  -  The  DCE  privilege  service  is  active  at  login,  by 
providing  an  authenticated  principal  (user)  with  a  Extended  Privilege  Attribute  Certificate 
(EPAC).  This  EPAC  is  a  ticket  that  proves  the  identity  of  the  principal  (user)  logging  in  by 
indicating  not  only  his  principal  (singular  identity)  but  also  the  registry  groups  that  the 
principal  belongs  to. 

Full  Binding  -  see  String  Binding 

Function  -  Logic  executed  within  a  program  that  has  discrete  inputs  and  outputs. 

Global  Directory  Agent  (GDA)  -  A  DCE  process  (called  gdad)  that  provides  the  interface  from  the 
CDS  to  either  DNS  or  GDS  in  order  to  locate  a  remote  cells  and  their  resources  within. 

Giobal  Directory  Service  or  GDS  -  The  CCiTT  X.500/ISO  9594  Directory  Service  is  a  general 
purpose  naming  database  that  provides  a  similar  service  to  the  Domain  Naming  Service 
(DNS).  DCE  cells  can  be  registered  in  GDS,  DNS  or  both  naming  services  in  order  that 
clients  in  one  cell  can  locate  servers  in  another  cell. 

Global  Server  -  A  DTS  global  server  is  able  to  provide  time  values  to  any  system  in  a  DCE  cell 
and  registers  its  services  in  the  /.:/cell-profile  object  in  the  CDS  namespace. 

Group  -  A  group  (in  the  context  of  the  DCE  registry)  is  a  coliection  of  related  principal  identities. 
This  is  very  similar  to  the  UNIX  /etc/group  file  in  form  and  contents. 

Group  Entry  or  NSI  group  entry  -  An  object  in  the  CDS  database  that  contains  a  list  of  CDS 
names  in  the  CDS  database.  This  effectively  is  a  "network  node"  in  the  networked  fabric  of 
pointers  contained  within  the  hierarchical  CDS  database. 

hostname  -  When  a  system  is  installed  in  a  DCE  cell,  the  directory  /.:/hosts/hostname  is 
automatically  created  in  the  CDS  database  and  the  principal  &  account  hosts/hostname/self 
is  created  in  the  Security  Registry  database.  Example,  when  the  host  "earth"  is  configured 
into  a  DCE  cell,  the  directory  /.:/hosts/earth  will  be  created  in  the  CDS  and  the  account 
hosts/earth/self  will  be  created  in  the  Registry. 

hosts  -  the  directory  (container)  called  "hosts"  in  the  Cell  Directory  Service  (CDS)  database  is  a 
database  directory  (not  a  filesystem  directory)  containing  other  directories  that  represent 
each  DCE  system  installed  in  a  particular  cell. 

IDL  -  Interface  Definition  Language.  This  is  a  language  (similar  to  C)  that  defines  the  data  types 
that  are  passed  between  a  particular  type  of  client  and  it's  server.  Usually  the  interface  is 
described  (created)  by  the  author  of  the  server  program  and  authors  of  client  programs  use 
the  definition  when  compiling  their  client  side  programs.  The  IDL  concept  was  contributed  to 
the  OSF/DCE  technology  suite  by  HP/Apollo. 

IDL  Compiler  -  An  IDL  Compiler  is  a  compiler  that  takes  files  written  in  a  language  called  IDL  and 
creates  C  header  files.  These  header  files  are  then  compiled  into  both  the  client  and  the 
server  part  of  a  DCE  application.  Also  generated  are  "stub"  files  that  are  object  files  used  by 
the  DCE  runtime  library  to  support  the  RPC  communications  tasks.  The  sub  files  are  linked 
into  the  final  executable  application  program.  These  stub  files  make  the  calls  to  the  DCE 
runtime  library  at  execution  time. 
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Intercell  -  When  DCE  cells  are  connected  together  using  GDS/DNS  through  the  GDA,  cell-to-cell 
communication  is  possible.  This  intercommunication  is  referred  to  as  intercell 
communication. 

Interface  Identifier  -  This  specifies  the  interface  UUID  and  interface  version  that  a  particuiar 
server  supports.  It  uniquely  defines  that  interface  in  the  entire  globe.  The  interface  id  is 
hatxlcoded  into  the  IDL  files  speechifying  the  interface,  thus  clients  locate  servers  using  the 
interface  id. 

Interface  UUID  -  An  interface  UUID  is  a  UUID  that  refers  to  an  interface  that  a  server  process 
supports.  For  example,  suppose  we  have  a  client/server  image  viewing  application.  The 
designer  of  this  application  may  specify  that  the  server  must  receive  a  set  of  character  data 
(to  indicate  the  pathname  of  the  file  to  display)  and  the  server  must  return  to  the  client  floating 
point  numbers  that  make  up  the  basis  of  an  image.  This  definition  of  in  and  out  data  types 
supported  by  an  application  is  the  applications'  interface.  This  interface  is  uniquely  identitifed 
with  a  UUID  (an  interface  UUID). 

Interface  Version  -  An  interface  version  is  added  to  the  interface  identifier  to  enable 
enhancements  to  the  interface  without  disrupting  pre-existent  clients.  This  effectively 
conserves  the  use  of  interface  UUIDs  and  allows  one  to  become  familiar  with  frequently  used 
interface  UUIDs. 

Interoperability  -  A  computing  system  is  said  to  be  interoperable  if  computers  in  that  system  are 
able  to  interact  with  other  similar  and  dissimilar  computer  systems  successfully. 

Kerberos  -  Kerberos  is  an  authentication  scheme  that  was  originally  developed  at  MIT.  The  DCE 
security  service  implements  version  5  of  this  protocol  and  is  incompatible  with  earlier  versions 
of  the  protocol.  DCE  has  extended  the  protocol  with  the  use  of  Priviledge  Attribute 
Certificates. 

Key  -  In  DCE,  the  temi  key  often  refers  to  a  binary  representation  of  a  password. 

Key  Files  or  Keytab  -  A  keytab  file  (or  key  table  file)  is  a  file  that  stores  a  password  (key)  for  a 
principal/account  (typically  for  a  server  process  or  machine  host).  Server  processes  and 
computers,  like  ordinary  users,  are  required  to  log  in  in  a  DCE  environment.  They  need  to 
store  their  login  passwords  in  some  forni  of  stable  storage  -  hence  a  file  is  used.  The  file  is 
weakly  encrypted  and  is  created  using  the  dcecp  control  program. 

LAN  -  Local  Area  Network  implemented  as  a  ethemet,  token-ring,  Fiber  Distributed  Data 
Interchange  (FDDI)  or  similar  technology.  LANs  have  the  characteristic  of  being  high  speed 
and  fairly  reliable  versus  WANs. 

lan-profile  •  A  profile  entry  in  the  CDS  database.  It  is  a  special  entry  in  that  it  is  used  to  help  a 
client  locate  other  information  in  the  CDS  database  i.e.  it  is  part  of  the  "search  engine"  used 
internally  by  CDS.  The  lan-profile  may  contain  references  to  server  entries  (binding 
information)  for  server  processes  that  exist  in  a  single  LAN. 

Leap  Seconds  -  UTC  time  is  not  based  on  the  rotation  of  the  earth.  UTC  time  therefore  must  be 
re-synchronized  with  the  rotation  of  the  earth  periodically.  This  adjustment  in  UTC  is 
performed  by  moving  the  UTC  time  by  one  second.  DCE  systems  do  not  handle  gross  time 
adjustments  like  this  well  -  so  at  the  time  UTC  moves  by  a  second,  DCE  time  does  not. 
Instead  DCE  increases  it's  inaccuracy  by  a  second  and  gradually  adjusts  to  remove  the  1 
second  error. 

Local  Server  -  A  DTS  local  server  is  one  that  provides  time  values  to  systems  within  a  Local  Area 
Network  (LAN).  By  default,  local  servers  register  their  interfaces  identifiers  in  the  /.:/lan- 
profile  object  of  the  CDS  anmespace. 

Maximum  Inaccuracy  or  maxinaccuracy  •  Maximum  inaccuracy  is  a  configurable  parameter  in 
DTS.  It  controls  how  tightly  coupled  systems  are  with  respect  to  time. 
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Member  Name  -  In  the  context  of  an  NSI  profile,  the  member  name  is  the  CDS  path  that  this 
element  of  the  profile  points  to  (i.e.  what  server  does  this  element  of  the  profile  point  to ). 

Namespace  -  a  namespace  is  the  logical  view  of  a  database  (of  some  kind).  For  example,  the 
CDS  namespace  is  a  hierarchical  directory  structure  representing  the  contents  of  the  CDS 
database. 

ncacnjp_tcp  -  This  is  a  DCE  reference  to  the  protocol  sequence  within  a  binding  handle  used  by 
an  RPC  client/server.  In  this  case,  the  IP  protocol  has  two  main  flavors:  1)  tcp/ip  and  2) 
udp/ip.  The  former  is  a  connection  oriented  protocol  (cn)  and  the  latter  is  an  datagram 
protocol  (dg).  The  string  ncacn_ip_tcp  is  a  reference  to  the  former  (tcp/ip).  The  character 
string  is  made  up  as  follows  ; 

nca  -  network  computing  architecture  (this  just  means  DCE  RPC) 
cn  -  a  connection-oriented  protocol 

ip  -  the  IP  protocol  (Internet  Protocol)  used  to  connect  systems 

tcp  -  the  TCP  protocol  (Transmission  Control  Protocol)  used  on  top  of  IP 

ncadg_ip_udp  -  This  is  a  DCE  reference  to  the  protocol  sequence  within  a  binding  handle  used 
by  an  RPC  client/server.  In  this  case,  the  IP  protocol  has  two  main  flavors:  1)  tcp/ip  and  2) 
udp/ip.  The  former  is  a  connection  oriented  protocol  (cn)  and  the  latter  is  an  datagram 
protocol  (dg).  The  string  ncadgjp_udp  is  a  reference  to  the  latter  (udp/ip).  The  character 
string  is  made  up  as  follows : 

nca  -  network  computing  architecture  (this  Just  means  DCE  RPC) 
dg  -  a  datagram  (connectionless)  protocol 
ip  -  the  IP  protocol  (Internet  Protocol)  used  to  connect  systems 
udp-  the  UDP  protocol  (User  Datagram  Protocol)  used  on  top  of  IP 

Network  Protocol  or  protocol  -  A  communications  transport  such  as  UDP  or  TCP. 

NFS  -  the  "Network  File  System"  from  SunSoft  Inc.  NFS  is  an  alternate  file  sharing  environment 
like  DFS  or  Novell's  Netware. 

NSI  -  NSI  stands  for  Name  Service  Interface  -  The  search  and  retrieval  engine  inside  the  CDS 
database  that  helps  a  client  request  reach  appropriate  binding  information.  There  are  three 
kinds  of  NSI  entries  in  CDS: 

1)  A  server  entry  -  a  "boundary  node"  that  points  to  a  system  where  an  interface  is 
supported 

2)  A  group  entry  -  a  "network  node"  that  points  to  other  names  within  the  CDS  database 

3)  A  profile  entry  -  a  "network  node"  with  prioritized  pointers  to  other  names  within  the 
CDS  database 

Using  these  three  entry  types,  a  network  can  be  established  within  the  hierarchical  CDS 
database  that  a  client  can  easily  navigate  to  locate  applicable  servers. 

NTP  -  NTP  stands  for  the  Network  Time  Protocol  -  A  standard  used  to  synchronize  time  between 
systems  on  the  internet.  DTS  is  a  similar  protocol  but  makes  full  use  of  the  DCE  Directory 
and  Security  Services  whereas  NTP  is  not  DCE  aware. 

Object  UUID  -  Within  a  single  interface,  a  server  may  support  several  different  types  of  service, 
each  having  the  same  interface.  In  order  to  differentiate  between  these  services,  each 
service  may  have  a  unique  name  (an  object  UUID). 

Organization  -  An  organization  (like  a  registry  group)  is  a  collection  of  related  principal  identities. 
What  differs  an  organization  from  a  group  is  that  a  registry  policy  can  be  applied  to  every 
member  of  an  organization  e.g.  every  member  of  a  specific  organization  may  have  to  re¬ 
initialize  their  identity  (log  in  again)  every  six  hours  (rather  than  a  default  of  10  hours). 

Partial  Binding  -  see  String  Binding 

Password  -  A  string  of  characters  that  must  be  typed  by  a  user  wishing  to  log  in  (authenticate)  to 
a  DCE  Security  Server. 
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Periodic  skulking  -  CDS  wiii  automatically  try  to  send  updates  from  a  read/write  master  copy  of  a 
CDS  directory  to  the  copies  (or  replicas)  of  that  directory  stored  on  other  CDS  server  systems 
-  this  is  called  periodic  (or  automatic)  skulking. 

Policy  -  Registry  policies  control  such  things  as  "what  is  the  default  lifespan  of  a  DCE  ticket"  or 
"what  is  the  minimum  number  of  characters  that  are  required  for  a  DCE  password.  These 
policies  may  be  altered  for  the  registry  as  a  whole,  or  per  registry  organization. 

Port  -  see  Endpoint 

Privilege  -  The  DCE  privilege  service  is  active  at  login,  by  providing  an  authenticated  principal 
(user)  with  an  Extended  Privilege  Attribute  Certificate  (EPAC).  This  EPAC  is  a  ticket  that 
proves  the  identity  of  the  principal  (user)  logging  in  by  indicating  not  only  his  principal 
(singular  identity)  but  also  the  registry  groups  that  the  principal  belongs  to. 

Profile  Entry  or  NSI  profile  entry  -  An  object  in  the  CDS  database  that  contains  a  prioritized  list  of 
interface  identifiers  and  the  related  CDS  names  in  the  CDS  database.  This  effectively  is  a 
"network  node"  in  the  networked  fabric  of  pointers  contained  within  the  hierarchical  CDS 
database. 

Property  -  Properties  of  the  DCE  registry  apply  to  the  registry  as  a  whole.  An  example  of  a 
property  of  a  registry  is  whether  the  database  is  marked  as  read  only. 

Registry  or  Password  Registry  -  A  centralized  database  containing  login  account  information  for 
all  users,  processes  and  machines  in  a  DCE  cell. 

Release  skulking  -  Release  skulking  is  the  manual  process  of  forcing  an  update  from  a  read/write 
master  copy  of  a  CDS  directory  to  the  readonly  copies  (or  replicas)  of  that  directory  stored  on 
other  CDS  server  systems. 

Replica  or  Replication  -  Certain  centralized  DCE  databases  may  be  replicated  on  multiple 
systems  for  availability  and  performance  reasons.  That  is,  multiple  copies  (or  replicas)  of  the 
database  may  be  created.  Replication  of  DCE  databases  reduces  the  likelihood  that  DCE 
services  may  become  unavailable  because  of  a  failure  of  a  single  system  since  other 
systems  (holding  copies  of  the  DCE  databases)  are  still  available.  The  DCE  Security  and 
Directory  services  can  be  replicated. 

rgy_edit  -  this  registry  editor  was  a  DCE  version  1.0  utility  that  accesses  the  DCE  registry 
database.  Much  of  the  functionality  of  rgy_edit  has  been  migrated  to  the  newer  "dcecp" 
command  suite  in  DCE  1.1. 

RPC  -  Remote  Procedure  Call  -  A  call  to  a  procedure  or  function  that  executes  on  the  local  or 
another  computer  system. 

RPC  Runtime  or  RPC  Runtime  Library  -  Code  that  executes  on  every  DCE  system.  This  code 
deals  with  the  complexities  of  connecting  to  a  remote  process  over  a  network  of  some  kind. 
The  RPC  runtime  is  needed  in  order  to  execute  any  DCE  based  RPC. 

rpccp  -  rpccp  (the  RPC  control  program)  is  a  DCE  version  1 .0  utility  that  accesses  RPC-related 
information  in  CDS  and  in  a  hosts  endpoint  database.  Much  of  the  functionality  of  rpccp  has 
been  migrated  to  the  newer  "dcecp"  command  suite. 

Scalability  -  A  computing  solution  is  scalable  if  ft  can  be  extensively  expanded  without  significant 
modification. 

seed  -  seed  is  the  security  server  process.  It  manages  accesses  to  the  security  database  (called 
the  registry)  and  all  centralized  security  functions  within  the  DCE  cell. 

Secure  -  In  DCE  terms,  a  secure  message  is  a  message  that  may  not  be  altered  during 
transmission  over  a  network  without  the  receiver  knowing  that  the  message  was  aKered. 
This  is  done  using  cryptographic  checksums. 
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Security  Server  -  The  process  (seed)  that  maintains  a  database  of  login  accounts  for  DCE 
identities  and  other  security  reiated  information.  It  provides  an  authentication,  privilege,  and 
certification  service  to  the  DCE  cell. 

Service  -  A  server  process  provides  a  service  of  some  kind  to  ciients.  This  service  involves 
executing  a  procedure  on  the  CPU  where  the  server  process  runs  and  returning  the  result  to 
the  client. 

Server  -  A  DCE  server  is  a  process  that  provides  a  service  to  clients  who  request  services.  This 
service  usually  involves  executing  logic  on  the  server's  local  CPU  and  returning  the  results  to 
a  client  (often  over  a  network). 

Server  Entry  or  NSI  server  entry  -  An  object  in  the  CDS  database  where  a  server  process 
registers  its  binding  information  (primarily  address  information  about  how  to  locate  the  server 
process).  This  effectively  is  a  "boundary  node"  in  the  networked  fabric  of  pointers  contained 
within  the  hierarchical  CDS  database. 

Server  process  or  server  -  A  process  that  provides  a  service  to  a  requesting  client  process.  The 
service  involves  execution  of  a  procedure  (or  function)  on  the  machine  running  the  server 
process.  Server  processes  may  listen  for  client  requests  indefinitely,  or  they  may  be  invoked 
only  when  a  client  request  is  made. 

Session  key  -  A  session  key  is  a  temporary  key  issued  by  the  security  service  to  both  a  client  and 
a  server  so  that  they  may  have  a  common  key  (or  password)  with  which  they  may  encrypt 
data  (if  they  choose  to).  The  first  session  key  obtained  by  as  user  is  a  session  key  obtained 
at  login. 

Skew  -  see  Clock  Skew 

Skulk  -  the  skulk  operation  copies  the  contents  of  a  read/write  CDS  directory  to  any  readonly 
replica  sites  that  have  been  defined  for  that  directory  i.e.  a  skulk  operation  might  copy  the 
CDS  directory  '7.:/hosts"  to  all  clearinghouses  that  hold  a  readonly  copy  of  "/.:/hosts". 

Soft  link  -  A  soft  link  is  the  CDS  equivalent  of  a  symbolic  link  in  a  Unix  filesystem.  It  appears  to 
be  a  directory  in  that  it  can  be  traversed.  A  soft  link  provides  an  alternate  path  to  a  CDS 
entity. 

String  binding  -  A  string  binding  is  an  character  representation  of  the  infonnation  needed  for  a 
DCE  client  to  connect  to  a  DCE  server.  It  contains  a  protocol  sequence,  an  IP  address,  and 
possibly  a  port  number.  Binding  information  is  stored  in  CDS  to  help  a  client  locate  a  server 
process.  This  binding  information  may  be  partial  or  complete.  Complete  binding  information 
includes  (among  other  things)  the  IP  address  of  a  computer  (where  the  server  process  runs) 
AND  an  endpoint  address  (on  which  the  server  process  listens).  Partial  binding  information 
does  not  include  this  endpoint  address.  By  convention,  only  partial  binding  information  is 
usually  stored  in  the  CDS  since  port  infonnation  changes  with  each  restart  of  a  server. 

Stub  file  -  A  stub  file  is  an  object  file  (.0  file)  that  is  linked  into  a  DCE  application.  The  stub  file  Is 
generated  by  compiling  an  IDL  file  with  an  IDL  compiler  -  a  stub  file  and  a  header  file  are 
generated.  Since  the  IDL  file  includes  a  definition  of  the  data  types  to  be  passed  between  a 
client  and  a  server,  the  stub  file  also  includes  these  definitions.  Hence  the  stub  file  is  the 
method  that  DCE  uses  to  "compile  in"  the  interface  definition  (between  client  and  server)  into 
a  DCE  executable.  Both  a  DCE  client  and  a  DCE  server  will  have  their  respective  stub  fiie 
linked  into  their  executable  programs.  This  stub  file  is  what  actually  calls  the  DCE  runtime 
library  at  execution  time. 

Threads  -  POSIX  Pthreads  -  A  specification  for  an  industry-standard  application  programming 
interface  for  executing  multiple  parallel  tasks  in  a  single  process.  DCE  threads  are  based  on 
the  POSIX  1003.4a  Draft  4  specification. 
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Ticket  -  The  DCE  security  service  issues  tickets  to  various  identities.  These  tickets  prove  the 
identity  of  the  person  or  process  receiving  the  ticket.  Tickets  usuaiiy  expire  or  become  invalid 
some  time  after  they  are  issued.  Tickets  are  used  rather  than  having  to  reenter  the  DCE 
secret  key  (password)  every  time  proof  of  identity  is  required. 

Ticket  cache  -  A  ticket  cache  is  a  directory  on  the  local  disk  of  a  DCE  client  system  that  houses 
the  tickets  that  are  obtained  from  the  DCE  security  service  on  behalf  of  a  user.  The 
permissions  on  the  elements  of  this  cache  (the  tickets  themselves)  need  to  be  carefully 
controlled  by  local  operating  system  security.  If  you  are  able  to  read  another  persons  ticket, 
you  may  masquerade  as  that  person  for  a  limited  period  of  time. 

Ticket  Granting  Ticket  or  TGT  -  The  first  ticket  issued  to  a  user  upon  successful!  login.  This  ticket 
proves  the  identity  of  a  principal.  It  may  be  used  to  obtain  other  tickets  (for  other  client/server 
transactions). 

Time  clerk  -  In  reference  to  DTS,  a  clerk  is  a  client. 

Time  Differential  Factor  or  TDF  -  The  difference  between  UTC  time  and  the  local  time  zone  time. 
For  example,  time  in  New  York  City  in  December  is  five  hours  less  than  the  UTC  time. 

Time  provider  -  A  time  provider  is  a  process  that  obtains  time  from  an  external  source  and 
provides  that  time  to  a  DTS  server  (often  a  global  server). 

Time  source  -  The  place  a  time  provider  gets  an  accurate  time  value  from. 

Time  inaccuracy  -  Since  time  calculations  can  never  be  totally  accurate,  DTS  specifies  that  the 
true  time  lies  within  a  range  (say  4pm  +/- 1  sec).  In  this  example  the  current  inaccuracy  is  1 
sec. 

UTC  or  Universal  Coordinated  Time  •  An  international  time  standard  that  has  replaced  Greenwich 
Mean  Time  (GMT).  UTC  does  not  base  its  time  on  the  rotation  of  the  earth,  but  rather,  on  an 
atomic  measurement. 

UUID  -  stands  for  Universal  Unique  IDentifier.  UUIDs  are  128  bit  numbers  that  are  used 
internally  by  DCE  as  unique  names  for  any  kind  of  resource.  Once  created,  UUIDs  are 
unique  in  time  and  space  since  they  include  temporal  and  physical  information  as  part  of  the 
coding  scheme.  For  example  a  user  name  such  as  "neil"  will  have  associated  with  it  a  UUID 
such  as  01e363e43-1234-5536-0802b37421e.  This  uniquely  identifies  "neil"  through  the 
entire  globe  so  there  will  never  be  ambiguity  who  this  really  is. 

Wide  Area  Network  or  WAN  -  A  wide  area  network  provides  computer  connectivity  over  a  greater 
distance  than  is  involved  in  local  area  network  connections.  Wide  area  networks  generally 
are  unlikely  to  be  available  100%  of  the  time  i.e.  they  are  less  reliable  than  Local  Area 
Networks  (LANs). 

X.500  -  The  reference  to  the  CCITT  standard  with  which  DCE  can  inter-operate. 
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